Re: Problems with pthreads from a shared object?

[Rich Felker <dalias@libc.org>]

On Thu, Nov 08, 2018 at 09:53:38AM -0500, Barry Flartus wrote:
> >
> > Sorry to butt-in.
> >
> > Alpine Linux uses musl. BF won't need anything special to use or
> > exercise musl (and certainly won't need to worry about
> > cross-pollination).
> >
> 
> Jeff, no worries about butting in. Could you clarify your statement?
> Im not quite sure I understand your cross-pollination analogy :)

I think it would be helpful to understand what you're trying to do.

If your goal is just ensuring your application is compatible with musl
so that it can be built and used on musl-based systems/distros, using
one (such as Alpine, or Adelie, or Void with musl, or Sabotage, etc.),
possibly in a container, is going to be the easiest way to achieve
that.

If your goal is building an application with musl and dlopen'd modules
that you can deploy to systems that might or might not be musl-based,
this can be done, but requires using dynamic linking and some glue for
explicitly running the dynamic linker, since it can't be found via a
fixed absolute path the way 'native' dynamic linking works.

If your goal is to get around the glibc limitation that loading
libpthread dynamically doesn't work, trying to use musl to produce .so
files that use threads that glibc-linked programs can load, this
simply does not, and cannot, work. A much better simpler solution is
just ensuring the main program always links with -lpthread when using
glibc.

Rich