|
Message-ID: <CAJ86T=WmaQUjtWsie92xn2ozEhQ5upug5vBrtLx2HXBE4PTbyA@mail.gmail.com> Date: Tue, 10 Mar 2020 12:52:27 -0700 From: Andre McCurdy <armccurdy@...il.com> To: musl@...ts.openwall.com Subject: Re: musl and jemalloc support On Tue, Mar 10, 2020 at 8:48 AM Rich Felker <dalias@...c.org> wrote: > On Tue, Mar 10, 2020 at 03:04:48PM +0100, Kaisrlík, Jan wrote: > > On Tue, Mar 10, 2020 at 2:41 PM Rich Felker <dalias@...c.org> wrote: > > > On Tue, Mar 10, 2020 at 12:08:57PM +0100, Kaisrlík, Jan wrote: > > > > > the fact that you have libpthread.so means it's not a musl system > > > > > and preloading a libpthread.so from another libc is expected to > > > > > crash. (even on other systems you should not just preload libpthread, > > > > > but libjemalloc should have it in its dependencies if needed.) > > > > > > > > Sorry, I kept libpthread from one of my previous tests which is slightly > > > > misleading in this case. My system has only one libpthread library coming > > > > from musl. > > > > > > musl has no libpthread.so, only libpthread.a (which is empty). If you > > > have a libpthread.so, something probably went badly wrong in setting > > > up your system. > > > > Thank you for pointing this. Fortunately, it is symlink to libc. > > > > ls -la usr/lib/libpthread.so > > lrwxrwxrwx 1 X X 7 Mar 5 15:02 usr/lib/libpthread.so -> libc.so > > That's still wrong. Recent musl will go out of its way to prevent you > from shooting yourself in the foot like that, but older musl will blow > up horribly. In either case the file should not exist. OpenEmbedded provides those symlinks (although some are only as part of a glibc compatibility package and so not generally exposed to users): https://git.openembedded.org/openembedded-core/tree/meta/recipes-core/musl/musl_git.bb#n73 Is that wrong?
Powered by blists - more mailing lists
Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.