Re: Removing glibc from the musl .2 ABI

[Rich Felker <dalias@libc.org>]

On Wed, Jul 24, 2019 at 07:36:00PM +0200, Szabolcs Nagy wrote:
> * James Y Knight <jyknight@google.com> [2019-07-24 09:33:05 -0700]:
> > One thing I've not seen mentioned yet: if this is done, then anyone
> > (whether intentionally or inadvertently) who links any glibc-compiled .o or
> > .a files into a musl binary/shared-lib will be broken.
> > 
> > Up until now, with musl's mostly-glibc-compatible ABI, you could link the
> > two object files together, and generally expect it to work. When
> > compatibility is instead done with magic in the dynamic loader, that
> > obviously can only ever work with a shared-object boundary.
> > 
> > I don't know if anyone actually uses musl in a context where this is likely
> > to be a problem, but it at least seems worth discussing (and loudly
> > documenting as a warning to users not to do this if implemented).
> 
> is it common that binary only .o or .a is distributed?
> 
> binary only shared libs with glibc dependency are fairly
> common (plugins, userspace driver code etc). i think the
> abi compat was mainly intended to support that.

It may be common with proprietary middleware or userspace-drive stuff
for hardware devices, where presumably the idea of shipping a static
lib rather than a shared one is that you don't ship usable copies of
the middleware vendor's library too your customers along with your
product.

Rich