[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20200310201704.GB11469@brightrain.aerifal.cx>
Date: Tue, 10 Mar 2020 16:17:04 -0400
From: Rich Felker <dalias@...c.org>
To: musl@...ts.openwall.com
Subject: Re: musl and jemalloc support
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.
Rich
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.
