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 <dclarke@xxxxxxxxxxxxx> 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
