OpenSSL version 3.3.0 published

Dennis Clarke dclarke at blastwave.org
Wed May 15 20:12:20 UTC 2024


On 5/13/24 03:34, Matt Caswell wrote:
> 
> 
> On 13/05/2024 02:42, Neil Horman wrote:
>> We added support for RCU locks in 3.3 which required the use of 
>> atomics (or emulated atomic where they couldn't be supported), but 
>> those were in libcrypro not liberal
>>
> 
> Right - its supposed to fallback to emulated atomic calls where atomics 
> aren't available on a particular platform.
> 
> Some platforms have some atomics support but you have to link in a 
> separate atomics library to get it to work. You might try adding 
> "-latomic" to Configure command line and see if that helps at all.
> 
Well first the good news : managed to get past the need for C11 atomics
with the bundled libatomic.so.1 that the Oracle people provide in the
dev tools.

      So that works now.  Yay.

Now comes the next horrible hurdle to jump and that seems to be called
the quic protocol goodness.  For the record I am able to get a good
result if I go with "no-quic" in the config :

hubble $ $PERL ./Configure solaris64-sparcv9-cc \
 > --prefix=/opt/bw no-asm no-engine shared zlib-dynamic \
 > no-quic enable-weak-ssl-ciphers -DPEDANTIC 2>&1
Configuring OpenSSL version 3.3.0 for target solaris64-sparcv9-cc
Using os-specific seed configuration
Created configdata.pm
Running configdata.pm
Created Makefile.in
Created Makefile
Created include/openssl/configuration.h

**********************************************************************
***                                                                ***
***   OpenSSL has been successfully configured                     ***
***                                                                ***
***   If you encounter a problem while building, please open an    ***
***   issue on GitHub <https://github.com/openssl/openssl/issues>  ***
***   and include the output from the following command:           ***
***                                                                ***
***       perl configdata.pm --dump                                ***
***                                                                ***
***   (If you are new to OpenSSL, you might want to consult the    ***
***   'Troubleshooting' section in the INSTALL.md file first)      ***
***                                                                ***
**********************************************************************
hubble $


That all builds neatly on this old platform and all the testsuite looks
to be sweet :

.
.
.
All tests successful.
Files=312, Tests=3182, 6723 wallclock secs (25.17 usr  3.15 sys + 
6375.57 cusr 171.52 csys = 6575.41 CPU)
Result: PASS
`test' is up to date.

So that is cute.

However, if I leave in the "quic"-ness then I eventually land on this
weird linking problem :

Undefined                       first referenced
  symbol                             in file
ossl_quic_rxfc_get_final_size       test/cert_comp_test-bin-cert_comp_test.o
ossl_quic_sstream_get_final_size    test/cert_comp_test-bin-cert_comp_test.o
ossl_quic_vlint_decode_unchecked    test/cert_comp_test-bin-cert_comp_test.o
ld: fatal: symbol referencing errors. No output written to 
test/cert_comp_test
*** Error code 2
make: Fatal error: Command failed for target `test/cert_comp_test'
Current working directory /opt/bw/build/openssl-3.3.0_SunOS_5.10_SPARC64.004
*** Error code 1
make: Fatal error: Command failed for target `build_sw'

These files refer to the above symbols :

1) headers
-rw-r--r--   1 dclarke  devl        4670 Apr  9 12:12 
./include/internal/packet_quic.h
-rw-r--r--   1 dclarke  devl       10769 Apr  9 12:12 
./include/internal/quic_fc.h
-rw-r--r--   1 dclarke  devl       17692 Apr  9 12:12 
./include/internal/quic_stream.h
-rw-r--r--   1 dclarke  devl       34987 Apr  9 12:12 
./include/internal/quic_stream_map.h
-rw-r--r--   1 dclarke  devl        4212 Apr  9 12:12 
./include/internal/quic_vlint.h

2) C sources
-rw-r--r--   1 dclarke  devl        2060 Apr  9 12:12 ./crypto/quic_vlint.c
-rw-r--r--   1 dclarke  devl      121348 Apr  9 12:12 ./ssl/quic/quic_impl.c
-rw-r--r--   1 dclarke  devl       12010 Apr  9 12:12 
./ssl/quic/quic_sstream.c
-rw-r--r--   1 dclarke  devl       26592 Apr  9 12:12 
./ssl/quic/quic_stream_map.c
-rw-r--r--   1 dclarke  devl       17658 Apr  9 12:12 
./ssl/quic/quic_tserver.c
-rw-r--r--   1 dclarke  devl      114209 Apr  9 12:12 ./ssl/quic/quic_txp.c

Looking into my compile logs I see that quic_vlint.c gets processed into
three output objects :

{CC foo} -c -o crypto/libcrypto-lib-quic_vlint.o   crypto/quic_vlint.c
{CC foo} -c -o crypto/libcrypto-shlib-quic_vlint.o crypto/quic_vlint.c
{CC foo} -c -o crypto/libssl-shlib-quic_vlint.o    crypto/quic_vlint.c

I see that quic_impl.c gets processed into two output objects :

{CC foo} -c -o ssl/quic/libssl-lib-quic_impl.o     ssl/quic/quic_impl.c
{CC foo} -c -o ssl/quic/libssl-shlib-quic_impl.o   ssl/quic/quic_impl.c


Similarly we see that quic_sstream.c results in two objects also :

     output object file                      input source
     ------------------------------------------------------------------
     ssl/quic/libssl-lib-quic_sstream.o      ssl/quic/quic_sstream.c
     ssl/quic/libssl-shlib-quic_sstream.o    ssl/quic/quic_sstream.c


Next I see quic_stream_map.c results in two object files :

     output object file                      input source
     ------------------------------------------------------------------
     ssl/quic/libssl-lib-quic_stream_map.o   ssl/quic/quic_stream_map.c
     ssl/quic/libssl-shlib-quic_stream_map.o ssl/quic/quic_stream_map.c


Same situation again for quic_tserver.c :

     output object file                      input source
     ------------------------------------------------------------------
     ssl/quic/libssl-lib-quic_tserver.o      ssl/quic/quic_tserver.c
     ssl/quic/libssl-shlib-quic_tserver.o    ssl/quic/quic_tserver.c

Lastly we see quic_txp.c gives us two objects also :

     output object file                      input source
     ------------------------------------------------------------------
     ssl/quic/libssl-lib-quic_txp.o          ssl/quic/quic_txp.c
     ssl/quic/libssl-shlib-quic_txp.o        ssl/quic/quic_txp.c


Looking at the above I can only guess that we are creating objects to
be linked later into a shared lib as well as object to be tossed into
a static lib AR type foo.a result. Just a guess.

None of the above seem involved with the stuff in the test directory and
clearly not a test/cert_comp_test-bin-cert_comp_test.o object file.

So ... what is going on here ?


--
Dennis Clarke
RISC-V/SPARC/PPC/ARM/CISC
UNIX and Linux spoken



More information about the openssl-users mailing list