On 10/1/15 10:14 AM, Ian Stakenvicius wrote:
-----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?
Nope. You're going to get into a lot of trouble doing that. Here's
some more toy code:
http://dev.gentoo.org/~blueness/misc/multipath-soname.tar.bz2
Unpack and run `make consumer`. It will build and install two libraries
at /lib/libstuff.so and /usr/lib/libstuff.so. These are identical
including their SONAMES but the first has symbol stuff@@STUFF1 while the
second has stuff@@STUFF2. It also installs a header file at
/usr/include/stuff.h. (So be careful not to clobber any such files that
might be on your system!)
It then builds an executable called consumer using `gcc -o $@ $<
-lstuff`. Running `readelf -sW consumer | grep stuff` gives
4: 0000000000000000 0 FUNC GLOBAL DEFAULT UND stuff@STUFF2 (3)
43: 0000000000000000 0 FUNC GLOBAL DEFAULT UND stuff@@STUFF2
but running `ldd consumer`
./consumer: /lib64/libstuff.so: version `STUFF2' not found (required by
./consumer)
linux-vdso.so.1 (0x000002919e40d000)
libstuff.so => /lib64/libstuff.so (0x000002919dfea000)
libc.so.6 => /lib64/libc.so.6 (0x000002919dc3f000)
/lib64/ld-linux-x86-64.so.2 (0x000002919e1ec000)
Uh oh! Something went very very wrong. Its an exercise for the reader
to see what when wrong.
The libraries should have different filenames and different sonames. I
think we're getting far off topic here.
Again, we can overcome this but its too much work in my opinion.
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?)
In the case of binary pkgs, you're SOL. The ebuild will have to encode
the intelligence needed to avoid installing (or at least warn) that you
are installing a binary pkg that requires openssl on a system that is
built around libressl.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2
iF4EAREIAAYFAlYNP7YACgkQAJxUfCtlWe3bFAEAtNa6rrLohwL0iQ/I64BaPhnw
HBZiG/I2kwRWOVujDz4A/iivzF8wsG8f84mTLyn9VebGoKHFNgf52bw6erXFD/rT
=jD6F
-----END PGP SIGNATURE-----
--
Anthony G. Basile, Ph.D.
Gentoo Linux Developer [Hardened]
E-Mail : bluen...@gentoo.org
GnuPG FP : 1FED FAD9 D82C 52A5 3BAB DC79 9384 FA6E F52D 4BBA
GnuPG ID : F52D4BBA
