Re: Symbol versioning approximation trips on compat symbols

[Timo Teras <timo.teras@iki.fi>]

On Mon, 28 Jan 2019 07:34:25 +0100
Florian Weimer <fweimer@redhat.com> wrote:

> * u-uy:
> 
> > On Sat, Jan 26, 2019 at 11:04:24PM -0500, Rich Felker wrote:  
> >> For what it's worth, compat symbols would have let us remove
> >> symbols that shouldn't have been put in musl, such as lchmod
> >> (which confuses broken apps which wrongly expect that, if it
> >> exists, it should work)  
> >
> > For what my integrator perspective is worth, exposing brokenness
> > instead of catering for it is a Good Thing.
> >
> > Feature detection is one of the typical areas being messed up, in
> > numerous softwares.
> >
> > Thanks musl for exposing the pitfalls and forcing upstreams think
> > better.  
> 
> As I explained, precisely that is not the case because the main musl
> user, Alpine Linux, builds musl with a broken toolchain that is not
> properly targeted to musl's features.  I think the official musl
> instructions have the same result.

I remember trying to build tool chain with symbol versioning disabled.
However, it did not work out.

It's long time ago, and I don't remember exacts (if it was build
failure, or run time failure). Could be that the symbol version
extension stop working failing build of various software.

Or maybe it was that the libgcc builds with symbol versioning
enabled/disabled are not compatible, so we would also lose glibc
compatibility if we disabled.

But what I remember that it did not work at all. Perhaps it was just
broken gcc version or something like that.

In any case, I came to conclusion that toolchain with symbol versions
disabled on linux did not fell like first class citizen.

Or maybe I just messed up something.

Has anyone built toolchain with symbol versions disabled from recent
binutils+gcc and used that to build a non-trivial amount of software?
Say 100+ packages?

Timo