Re: [musl] musl and jemalloc support

[Andre McCurdy <armccurdy@gmail.com>]

On Tue, Mar 10, 2020 at 8:48 AM Rich Felker <dalias@libc.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@libc.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?