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
