OpenSSL version 3.3.0 published

[Dennis Clarke]

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