[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
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.
