On 5/15/24 18:34, Neil Horman wrote:
You are correct, the files you reference (most of them in fact) get built
into separate objects in the event the build flags are different for shared
and static libraries, and should be unrelated to the issue you are seeing
I was somewhat puzzled by this also. Yes.
As for the undefined symbols, thats definitely a mystery. most notably,
the symbols referenced are internal. That is to say they shouldn't be
exported in the symbol table for libssl.so (though a quick look with
objectdump shows they are, which may be a separate issue)
Looking at the sources, I can see what _might_ be happening
cert_comp_tests.c includes "../ssl/ssl_local.h"
if quic is enabled (i.e. OPENSSL_NO_QUIC is undefined), ssl_local.h
includes quic/quic_local.h
quic_local.h includes internal/quic_txp.h
quic_txp.h includes internal/quic_stream_map.h
quic_stream_map.h defines a static inline function
named ossl_quic_stream_recv_get_final_size which calls
ossl_quic_rxfc_get_final_size, which in turn
calls ossl_quic_rxfc_get_final_size
I'm guessing the other symbols have simmilar patterns.
I am still digging into the issue.
I thank you the thoughtful reply.
As to why its happening my first guess would be that more recent compilers
like gcc and clang do lazy symbol resolution, only resolving a subordonate
symbol, when its calling parent is found to be used. Given
ossl_quic_stream_recv_get_final_size isn't called anywhere in
comp_stream_test.c, the compiler disposes of the symbol prior to any need
to resolve its called symbols, and so everything is ok.
I also suspect a linker issue here and the sad fact is that the GNU
ld just will not suffice in this server. C'est la vie ici.
conversely (again, I'm guessing here) the solaris 5.10 compiler likely take
a more bulldozer-ish approach, leaving everything in the object file and
only stripping symbols after all resolutions are complete, leading to the
missing symbols error, despite its not being needed.
I have to laugh at the "bulldozer" idea as you are likely quite
correct there.
As to what to do about this...I'm unsure. The quick hack I would imagine
would be to move the definition of ossl_quic_stream_recv_get_final_size
into a c file (likely quic_stream_map.c) and just declare a prototype in
the quic_stream_map.h header, so as to avoid the unneeded symbol
resolution. You would have to lather rinse repeat with the other missing
symbols of course.
As to your prior question about how long the ability to support SunOS will
last, well, unfortunately I don't think any of us can say. I believe the
platoform you are building on is on our unadpoted platform list:
https://www.openssl.org/policies/general-supplemental/platforms.html
And while we endeavor to keep openssl building on as many platforms as
possible, its not feasible to cover all the currently
unmaintained platforms. You do have some agency here however. If you are
willing and interested, you could volunteer to be a community platform
maintainer for your target platform. This would entail you building
openssl on your adopted platform, and running the test suite routinely,
reporting bugs and fixing errors as they occur. Its not a small amount of
work, but it would be a significant contribution toward ensuring that
openssl stays viable on the targets you need.
I can tell you that this morning I see :
.
.
.
All tests successful.
Files=312, Tests=3182, 6714 wallclock secs (25.22 usr 3.10 sys +
6370.32 cusr 170.55 csys = 6569.19 CPU)
Result: PASS
`test' is up to date.
hubble $ pwd
/opt/bw/build/openssl-3.3.0_SunOS_5.10_SPARC64.005
hubble $
hubble $ psrinfo -pv
The physical processor has 8 virtual processors (0-7)
SPARC64-VII+ (portid 1024 impl 0x7 ver 0xa1 clock 2860 MHz)
hubble $
hubble $ uname -a
SunOS hubble 5.10 Generic_150400-67 sun4u sparc SUNW,SPARC-Enterprise
hubble $
hubble $ hash -r
hubble $ which openssl
/opt/bw/bin/openssl
hubble $
hubble $ ldd /opt/bw/bin/openssl
libssl.so.3 => /opt/bw/lib/libssl.so.3
libcrypto.so.3 => /opt/bw/lib/libcrypto.so.3
libsocket.so.1 => /lib/64/libsocket.so.1
libnsl.so.1 => /lib/64/libnsl.so.1
libdl.so.1 => /lib/64/libdl.so.1
librt.so.1 => /lib/64/librt.so.1
libstatomic.so.1 => /opt/bw/lib/libstatomic.so.1
libc.so.1 => /lib/64/libc.so.1
libmp.so.2 => /lib/64/libmp.so.2
libmd.so.1 => /lib/64/libmd.so.1
libscf.so.1 => /lib/64/libscf.so.1
libaio.so.1 => /lib/64/libaio.so.1
libdoor.so.1 => /lib/64/libdoor.so.1
libuutil.so.1 => /lib/64/libuutil.so.1
libgen.so.1 => /lib/64/libgen.so.1
libm.so.2 => /lib/64/libm.so.2
/lib/sparcv9/../libm/sparcv9/libm_hwcap1.so.2
/platform/SUNW,SPARC-Enterprise/lib/sparcv9/libc_psr.so.1
hubble $ /opt/bw/bin/openssl version
OpenSSL 3.3.0 9 Apr 2024 (Library: OpenSSL 3.3.0 9 Apr 2024)
hubble $
Which seems to work like a charm and I do have a few patches.
What I would like to do is climb in and see what can be done to create a
pure ISO 9899:1990 clean code path. May be reduced in features but would
still work pretty much everywhere. Maybe.
Sure do wish I had my old Oracle support contract to update this server
a bit but they want a LOT of money for that.
--
Dennis Clarke
RISC-V/SPARC/PPC/ARM/CISC
UNIX and Linux spoken
