[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <87a7jq8iwg.fsf@oldenburg2.str.redhat.com>
Date: Thu, 24 Jan 2019 11:11:27 +0100
From: Florian Weimer <fweimer@...hat.com>
To: u-uy74@...ey.se
Cc: musl@...ts.openwall.com
Subject: Re: Symbol versioning approximation trips on compat symbols
* u-uy:
> 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.
That's certainly a valid position to take. But the reality is that all
toolchains that target musl have symbol versioning support built into
them today, just not in the dynamic linker. It would be far easier
unrelated upstreams if the toolchain simply did not support symbol
versioning at all (because the dynamic linker does not support it, so
it's not usable in each place where it is required anyway). Then a
simple check for .symver support in the assembler would tell us whether
we can symbol versionining or not.
I have no idea how this current support is supposed to work,
particularly with cross-compiling. Does everyone have to write
configure hacks for *-musl targets to disable symbol versioning support?
That goes against the mantra of testing what you use (and avoid
hard-coded knowledge about specific versions/targets).
Thanks,
Florian
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.
