|
Message-ID: <20181108151715.GA5150@brightrain.aerifal.cx> Date: Thu, 8 Nov 2018 10:17:15 -0500 From: Rich Felker <dalias@...c.org> To: musl@...ts.openwall.com Subject: Re: Problems with pthreads from a shared object? 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
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.