[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Fri, 28 Aug 2015 09:24:22 +0200
From: u-wsnj@...ey.se
To: musl@...ts.openwall.com
Subject: Re: Adjustments to roadmap
On Thu, Aug 27, 2015 at 10:43:48PM -0400, Rich Felker wrote:
> 3. Symbol versioning
>
> Right now musl's dynamic linker ignores symbol versioning information
> except to select the "current" version of a symbol the same way ld
> does. This is sufficient for most things, if you don't want to support
> old library ABIs and mixed (i.e. broken) ABIs, but it breaks some
> hacks GCC is doing in their target libs (libgcc_s.so, ...), and some
> setups that arguably "should" work, especially for C++ apps. What's
> probably worse is that you get silent breakage when an app is trying
> to use symbol versioning, expecting it to work, and it doesn't.
The symbol versioning is hardly the only or most straightforward
or most efficient way to manage ABI contracts between multiple parties.
I feel that it emerged to mitigate problems created by traditional
deployment practices. "Traditional" implies "formed in the past,
given differing prerequisites", aka suboptimal.
I our deployments symbol versioning is fully redundant, I'm happy
not having to deal with it with musl.
> I don't think the status quo is a reasonable option. We should either
> teach GCC that musl targets don't support symbol versioning, and make
> sure apps/libs' build systems detect this, or we should make them
> work. My leaning is towards the latter.
I'd rather prefer the former. Otherwise supporting an approach chosen for
unrelated reasons somewhere else imposes a certain complexity cost on musl
and on any packager/integrator who does not need versioning.
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.
