[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Wed, 24 Jul 2019 17:31:29 -0400
From: Rich Felker <dalias@...c.org>
To: musl@...ts.openwall.com
Subject: Re: Removing glibc from the musl .2 ABI
On Wed, Jul 24, 2019 at 07:36:00PM +0200, Szabolcs Nagy wrote:
> * James Y Knight <jyknight@...gle.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
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.
