Date: Tue, 10 Mar 2020 16:40:58 -0700 From: Andre McCurdy <armccurdy@...il.com> To: musl@...ts.openwall.com Subject: Re: musl and jemalloc support On Tue, Mar 10, 2020 at 1:17 PM Rich Felker <dalias@...c.org> wrote: > On Tue, Mar 10, 2020 at 12:52:27PM -0700, Andre McCurdy wrote: > > 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? > > Yes, it's wrong, and will lead to incorrect linking if these symlinks > are present when linking applications. Their presence does not help > with anything (glibc compat or otherwise) because musl's dynamic > linker intercepts these names and does not search for files. > > If you really really really think you need them for some runtime > reason for some application, they should probably be empty .so files > rather than symlinks to libc, and they should be in a directory where > they won't be searched by ld at link time. But it's almost certain > that whatever the motivation for putting them there in the first place > was based on a misunderstanding. Thanks. Khem created the links. Hopefully he's reading this and will either remove them or continue the thread if anything else needs clarification.
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.