Glad its working a bit better for you. If you are inclined, please feel free to open a PR with your changes for review.
Best Neil On Thu, May 16, 2024 at 7:40 AM Dennis Clarke <dcla...@blastwave.org> wrote: > 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 > >
