[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20190124092846.GA30123@example.net>
Date: Thu, 24 Jan 2019 10:28:46 +0100
From: u-uy74@...ey.se
To: musl@...ts.openwall.com
Subject: Re: Symbol versioning approximation trips on compat symbols
On Wed, Jan 23, 2019 at 08:43:40PM -0500, Rich Felker wrote:
> The same issue came up before with libgcc defining and referencing a
> non-default-version symbol for some weird compatibility hack. I don't
> remember the details but Szabolcs Nagy was involved in investigating
> and might. In any case, the root cause is that musl's dynamic linker
> does not support symbol versioning; for the sake of being able to load
> libraries that were build with versioning, it always resolves a symbol
> to the "latest"/default version, the same as ld would do at link time.
> Normally this is the right thing as long as you don't actually have
> things that were linked against an old incompatible version, but it
> also breaks explicit linking to a particular version as in your
> example above.
>
> The right fix is probably to add support for symbol version matching
> in the dynamic linker. Unfortunately this involves some extra logic in
> the extreme hot paths, so it's hard to make the cost unobservably low,
> and last I checked some members of the community were opposed to it on
> ideological grounds. If there's a good need for it (and I think just
IMVHO symbol versioning is basically aimed to hide the complexity of
the evolution of libraries, to make certain usage cases "just work".
OTOH it does not reduce the complexity under the hood but rather adds some
extra of it. That's why I see its impact as double negative, postulating
more complex tools and reducing the capacity of fellow integrators to
analyze their systems.
> avoiding silent breakage of third-party libs using versioning and
> intending for it to work is a fairly good one already), support can be
> added, but doing it without negative impact is a pretty big task.
This cost itself (of adding the support) means that some other useful
changes in musl will be missing at _every_ given time in the future
development. Is this workaround, for the sake of libraries who do unusual
hacks, really so important?
Rune
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.
