Re: [gentoo-dev] [RFC] Discontinuing LibreSSL support?

[Peter Stuge]

David Seifert wrote:
> > > I mean, you have to explicitly support the choice in ebuilds,
> > > and this means making things even harder for newcomers.
> >
> > pkg-config/pkgconf and .pc files can help with this part, taking care
> > of all abstraction if/when downstream uses a libressl.pc.
>
> As we have learned from the ncurses[tinfo] debacle, 80% of build systems
> don't use the .pc files, and just guess "-lssl" flags and a bunch of
> include dirs.

Did the debacle actually involve -lssl ?

I guess that it depends on the particular library - with an old library
such as ncurses I can imagine that .pc is much less established, and
I have indeed seen pretty ugly OpenSSL detection in configure.acs,
they could still remain, and would then simply never catch libressl,
I think that would be fine.


> > > The big problem is that (unless I'm mistaken) we won't be able to
> > > load LibreSSL and OpenSSL to the same executable.
> >
> > I'd suggest investigating whether symbol versioning could help with
> > this, or if the only way forward would indeed be to require some symbol
> > mangling/rewriting.
>
> While this sounds like a theoretical solution, it isn't tractable because
> 1. We're inventing our own ABI that is incompatible with everyone else's

ABI for a given library doesn't neccessarily matter beyond the
individual system, does it?

For something like reproducible builds of course it does.


> 2. We'd have to maintain a huge swamp of downstream patches

Nono, no patches of course, it would have to be automatic, if only for the
local system.


> 3. ABI can still break even with perfect symbol versioning

Oh? This may be unrelated, but can you tell more or provide a pointer?


Thanks!

//Peter