Hi John,
On 2021-07-27 03:03, John Lumby wrote:
On my linux system, (kernel is 5.10.46) , with openssl 1.1.1j built in its own
directory at /opt/openssl,
I run
./configure --disable-hardening --build-libxml2 --disable-pulse
--build-headless --enable-vnc --with-iasl=/usr/local/bin/iasl
--with-openssl-dir=/opt/openssl --disable-vmmraw --disable-java --disable-qt
--disable-docs
which fails with a zillion
/usr/local/bin/ld: ssl_init.c:(.text+0x4d): undefined reference to `xxx'
because configure has a line
LIBCRYPTO="${OPENSSLDIR}/lib/libcrypto.a ${OPENSSLDIR}/lib/libssl.a"
with the libs in the wrong order for what ld linker requires : libssl.a has
references to external symbols in
libcrypto.a .
the line should read
either
LIBCRYPTO="${OPENSSLDIR}/lib/libssl.a ${OPENSSLDIR}/lib/libcrypto.a -lpthread -ldl
-lm"
or
LIBCRYPTO="${OPENSSLDIR}/lib/libssl.so ${OPENSSLDIR}/lib/libcrypto.so"
configure runs without error if either --with-openssl-dir= is omitted (assuming
that package is in a standard location) or if --build-libssl is specified.
It is unusual for a package to deliberately choose to link to static libs
rather than dynamic-shared libs so I assume there was some reason for it, so
I don't know what other considerations there may be or what the best
correction is.
Taking a deep breath... yes, there is a reason. VirtualBox's configure
script is currently prepared to handle 3 cases for the openssl library.
1. Use the system openssl. Very easy, because it should be detected
automatically, without needing any special options to configure. It is
the best solution if you want to be able to update openssl without also
updating VirtualBox.
2. Point to a specific static openssl. Needs to be static because that
minimizes the effort for distribution (including a dynamic library in
the VirtualBox package is really not better than linking statically).
3. Tell the VirtualBox build system to compile the included openssl
library (see directory name src/libs/openssl* which version it currently
is). Also linked statically, for the same reason as 2.
Your approach seems to be halfway between 1. and 2., which no one needed
so far and it shouldn't replace any of the known working cases anyway,
so your diff would likely need to be more complicated.
However, you are right that case 2. was never really tested thoroughly
on Linux, so I just made the necessary adjustments. They will be in the
source for 6.1.28.
Hope this makes the logic somewhat clear...
BTW, openssl is at version 1.1.1k currently (we learned the hard way,
too, because we watch for new versions but their changelog page until
today doesn't have a proper release date for 1.1.1k - still says "[xx
XXX xxxx]"), which is in 6.1.26.
Klaus
Cheers, John Lumby
_______________________________________________
vbox-dev mailing list
vbox-dev@virtualbox.org
https://www.virtualbox.org/mailman/listinfo/vbox-dev
