-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 30/09/15 03:29 PM, Anthony G. Basile wrote: > On 9/30/15 12:18 PM, Ian Stakenvicius wrote: On 30/09/15 07:42 > AM, hasufell wrote: >>>> * libressl has to conflict with openssl > Right now libressl exports many of the same symbols as openssl > right? What if it didn't -- that is, we forced a symver map with > a libressl prefix on all symbols? That would ensure anything > built against libressl would not b0rk if openssl was loaded, or > more specifically, if something else was loaded that was built > against and links to openssl. > >> Yes you could use symbol versioning, and you can do the side by >> side by renaming the library but that's a real pita for us >> since we'd have to hack build systems to link against the >> correct library name. Ths should have been done upstream.
Library doesn't have to be renamed as long as it's in a different path, does it? If openssl/libssl.so is loaded and none of the symbols exist due to the symbols expected being 'libressl_*', then libressl/libssl.so being loaded will provide the necessary symbols and not conflict, right? Or am i missing something subtle here, like that libressl/libssl.so will never be loaded because the libssl.so from openssl/ was loaded? Note in the above i'm specifically not addressing side-by-side lib installation here and getting rdeps to build against the right ones - -- just how rdeps use libssl.so if two different ones were installed. On dealing with side-by-side installation in rdeps, technically don't we just start filing en masse "use pkg-config" patches to upstreams? we could just start doing that now couldn't we? It's 2015, shouldn't everything be using pkg-config or similar to find libs by now? > >> @rich0. Just a side comment. You said somewhere that maybe >> apache will choose openssl and postfix libressl and then we'll >> be in trouble. No. The incompatibility is at the abi not api >> level. So, for example, some struct size might be different >> between the two because of internal implementation details, but >> both should provide a definition of the same struct in their >> header with the same members. ie. apache should compile against >> either openssl or libressl and work, you just can't swap out >> your libssl without recompiling apache which you could do if >> you had full api compat. What happens in the case of a proprietary binary package that links to libssl? Even if we bundle the libssl.so variant that it needs, don't we run the risk of the package using the wrong one (esp. in the case where that package is i.e. dlopen'ed by something else?) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iF4EAREIAAYFAlYNP7YACgkQAJxUfCtlWe3bFAEAtNa6rrLohwL0iQ/I64BaPhnw HBZiG/I2kwRWOVujDz4A/iivzF8wsG8f84mTLyn9VebGoKHFNgf52bw6erXFD/rT =jD6F -----END PGP SIGNATURE-----
