[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20190130145719.GI23599@brightrain.aerifal.cx>
Date: Wed, 30 Jan 2019 09:57:19 -0500
From: Rich Felker <dalias@...c.org>
To: musl@...ts.openwall.com
Subject: Re: (OT?) Re: Symbol versioning approximation trips on
compat symbols
On Tue, Jan 29, 2019 at 06:13:05PM +0100, u-uy74@...ey.se wrote:
> On Mon, Jan 28, 2019 at 10:29:12AM -0500, Rich Felker wrote:
> > On Mon, Jan 28, 2019 at 02:08:13PM +0100, u-uy74@...ey.se wrote:
> > > If there is a feature which is hard or impossible to test for, like
> > > symbol versioning, it means that the applications may _have_ to rely on
> > > an explicit build flag telling whether to use it.
>
> > It wouldn't be hard to test for if toolchains had been consistent with
> > musl capabilities all along. They have not been. So we have a
> > situation where the valid build-time tests indicate support, but
> > runtime silently lacks it. I don't think this is a good situation to
>
> What is the value (the "validity"?) of a build-time test if it
> does not help to distinguish how to build a usable binary?
> This seems to be testing for A when we want to know B.
It's valid in that it works assuming the relevant components are
following the reasonable rules/spec for what to do, which was designed
to work in such a manner that it's safely detectable at configure
time. In particular the tooling should only be offering symver support
on targets that support it. We screwed up by not suppressing that in
gcc a long time ago, but I think we probably would have hit more
package-level breakage (that would have led to fruitless arguments and
had negative impact on ability to work with upstreams) if lack of
support stopped packages at build time rather than just silently
breaking later if mismatched lib versions are use.
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.
