Re: OpenSSL version 3.3.0 published

[Dennis Clarke via openssl-users]

On 5/16/24 08:28, Neil Horman wrote:

Glad its working a bit better for you.  If you are inclined, please feel
free to open a PR with your changes for review.


Well, the changes are *really* trivial. Necessary and trivial.


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

Re: OpenSSL version 3.3.0 published

[Neil Horman]

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  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
>  

Re: OpenSSL version 3.3.0 published

[Dennis Clarke via openssl-users]

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 

Re: OpenSSL version 3.3.0 published

[Neil Horman]

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

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.

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.

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.

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.

Regards
Neil



On Wed, May 15, 2024 at 4:12 PM Dennis Clarke  wrote:

> 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   ***
> ***   and include the output from the following command:   ***
> ***

Re: OpenSSL version 3.3.0 published

[Dennis Clarke via openssl-users]

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   ***
***   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_sizetest/cert_comp_test-bin-cert_comp_test.o
ossl_quic_vlint_decode_uncheckedtest/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  devl4670 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  devl4212 Apr  9 12:12 
./include/internal/quic_vlint.h


2) C sources
-rw-r--r--   1 dclarke  devl2060 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.ocrypto/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

Re: OpenSSL version 3.3.0 published

[Matt Caswell]

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.


Matt




On Sun, May 12, 2024, 7:26 PM Dennis Clarke via openssl-users 
mailto:openssl-users@openssl.org>> wrote:



On 4/9/24 08:56, OpenSSL wrote:
 > -BEGIN PGP SIGNED MESSAGE-
 > Hash: SHA256
 >
 >
 >     OpenSSL version 3.3.0 released
 >     ==
 >


Trying to compile this on an old Solaris 10 machine and over and over
and over I see these strange things as Undefined symbols :

Undefined                       first referenced
   symbol                             in file
__atomic_store_4                    ./libssl.so
__atomic_fetch_add_4                ./libssl.so
__atomic_fetch_sub_4                ./libssl.so
atomic_thread_fence                 ./libssl.so
__atomic_load_4                     ./libssl.so
ld: fatal: symbol referencing errors. No output written to apps/openssl
gmake[1]: *** [Makefile:12601: apps/openssl] Error 2
gmake[1]: Leaving directory
'/opt/bw/build/openssl-3.3.0_SunOS_5.10_SPARC64.002'
gmake: *** [Makefile:1978: build_sw] Error 2


Those look like strange C11 atomics. Are they really needed somewhere?

I see include/internal/refcount.h talks about C11 atomics and yet the
entire code base is supposed to be C90 clean.  See section the OpenSSL
Coding Style policy :

https://www.openssl.org/policies/technical/coding-style.html


      Chapter 14: Portability

          To maximise portability the version of C defined in
          ISO/IEC 9899:1990 should be used. This is more commonly
          referred to as C90. ISO/IEC 9899:1999 (also known as C99) is
          not supported on some platforms that OpenSSL is used on and
          therefore should be avoided.


Perhaps I need to define OPENSSL_DEV_NO_ATOMICS ?


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

Re: OpenSSL version 3.3.0 published

[Dennis Clarke via openssl-users]

On 5/12/24 21: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



I see. I am having great difficulty with 3.3 on an old Sun SPARC64
server where there really is not any libatomic support. Well, there is
sort of but it is a hack. Given how portable the code is there must be a
configuration option somewhere to disable the need for those atomic ops.

Meanwhile, OpenSSL 3.0.x builds and tests flawlessly but ... how
long will that last?


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

Re: OpenSSL version 3.3.0 published

[Neil Horman]

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



On Sun, May 12, 2024, 7:26 PM Dennis Clarke via openssl-users <
openssl-users@openssl.org> wrote:

>
> On 4/9/24 08:56, OpenSSL wrote:
> > -BEGIN PGP SIGNED MESSAGE-
> > Hash: SHA256
> >
> >
> > OpenSSL version 3.3.0 released
> > ==
> >
>
>
> Trying to compile this on an old Solaris 10 machine and over and over
> and over I see these strange things as Undefined symbols :
>
> Undefined   first referenced
>   symbol in file
> __atomic_store_4./libssl.so
> __atomic_fetch_add_4./libssl.so
> __atomic_fetch_sub_4./libssl.so
> atomic_thread_fence ./libssl.so
> __atomic_load_4 ./libssl.so
> ld: fatal: symbol referencing errors. No output written to apps/openssl
> gmake[1]: *** [Makefile:12601: apps/openssl] Error 2
> gmake[1]: Leaving directory
> '/opt/bw/build/openssl-3.3.0_SunOS_5.10_SPARC64.002'
> gmake: *** [Makefile:1978: build_sw] Error 2
>
>
> Those look like strange C11 atomics. Are they really needed somewhere?
>
> I see include/internal/refcount.h talks about C11 atomics and yet the
> entire code base is supposed to be C90 clean.  See section the OpenSSL
> Coding Style policy :
>
>  https://www.openssl.org/policies/technical/coding-style.html
>
>  Chapter 14: Portability
>
>  To maximise portability the version of C defined in
>  ISO/IEC 9899:1990 should be used. This is more commonly
>  referred to as C90. ISO/IEC 9899:1999 (also known as C99) is
>  not supported on some platforms that OpenSSL is used on and
>  therefore should be avoided.
>
>
> Perhaps I need to define OPENSSL_DEV_NO_ATOMICS ?
>
>
> Dennis Clarke
> RISC-V/SPARC/PPC/ARM/CISC
> UNIX and Linux spoken
>
>

Re: OpenSSL version 3.3.0 published

[Dennis Clarke via openssl-users]

On 4/9/24 08:56, OpenSSL wrote:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256


OpenSSL version 3.3.0 released
==




Trying to compile this on an old Solaris 10 machine and over and over 
and over I see these strange things as Undefined symbols :


Undefined   first referenced
 symbol in file
__atomic_store_4./libssl.so
__atomic_fetch_add_4./libssl.so
__atomic_fetch_sub_4./libssl.so
atomic_thread_fence ./libssl.so
__atomic_load_4 ./libssl.so
ld: fatal: symbol referencing errors. No output written to apps/openssl
gmake[1]: *** [Makefile:12601: apps/openssl] Error 2
gmake[1]: Leaving directory 
'/opt/bw/build/openssl-3.3.0_SunOS_5.10_SPARC64.002'

gmake: *** [Makefile:1978: build_sw] Error 2


Those look like strange C11 atomics. Are they really needed somewhere?

I see include/internal/refcount.h talks about C11 atomics and yet the
entire code base is supposed to be C90 clean.  See section the OpenSSL
Coding Style policy :

https://www.openssl.org/policies/technical/coding-style.html

Chapter 14: Portability

To maximise portability the version of C defined in
ISO/IEC 9899:1990 should be used. This is more commonly
referred to as C90. ISO/IEC 9899:1999 (also known as C99) is
not supported on some platforms that OpenSSL is used on and
therefore should be avoided.


Perhaps I need to define OPENSSL_DEV_NO_ATOMICS ?


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