Solaris 10 80-test_ca failure

classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

Solaris 10 80-test_ca failure

Erik Forsberg-11

I have been having 32-bit only test failures from test_ca
for quite a while now on Solaris 10 (1.1.pre), Finally figured
out what is wrong.

I build both 32-bit and 64-bit libraries.
My /usr/local/bin/perl is always 64-bit,
used to be required for assembler support.

LD_PRELOAD is used to force newly built libs into the test process
using util/shlib_wrap.sh

So, when building 32-bit libs, shlib_wrap tries to preload a 32-bit
libcrypto/libssl into the 64-bit perl process when CA.pl is invoked.
This causes failure on Solaris 10, but seems to be ignored on Solaris 11.

There was specific support to handle 64-bit builds in shlib_wrap, this
method also needs to be used for 32-bit builds.

This patch makes it work in all cases for me.
Someone using SPARC should review what /usr/bin/file
reports for an old 32-bit SPARC library (if such still exists)
I have no access to SPARC hardware.


*** shlib_wrap.sh       Tue Feb 16 23:55:51 2016
--- /usr/local/src/openssl-1.1//shlib_wrap.sh   Tue Mar  1 23:21:23 2016
***************
*** 27,32 ****
--- 27,37 ----
                LD_PRELOAD_64="$LIBCRYPTOSO $LIBSSLSO"; export LD_PRELOAD_64
                preload_var=LD_PRELOAD_64
                ;;
+       *ELF\ 32*SPARC*|*ELF\ 32*80386*)
+               [ -n "$LD_LIBRARY_PATH_32" ] && rld_var=LD_LIBRARY_PATH_32
+               LD_PRELOAD_32="$LIBCRYPTOSO $LIBSSLSO"; export LD_PRELOAD_32
+               preload_var=LD_PRELOAD_32
+               ;;
        # Why are newly built .so's preloaded anyway? Because run-time
        # .so lookup path embedded into application takes precedence
        # over LD_LIBRARY_PATH and as result application ends up linking
--
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Reply | Threaded
Open this post in threaded view
|

Re: Solaris 10 80-test_ca failure

Rainer Jung-3
Am 03.03.2016 um 18:51 schrieb Erik Forsberg:

>
> I have been having 32-bit only test failures from test_ca
> for quite a while now on Solaris 10 (1.1.pre), Finally figured
> out what is wrong.
>
> I build both 32-bit and 64-bit libraries.
> My /usr/local/bin/perl is always 64-bit,
> used to be required for assembler support.
>
> LD_PRELOAD is used to force newly built libs into the test process
> using util/shlib_wrap.sh
>
> So, when building 32-bit libs, shlib_wrap tries to preload a 32-bit
> libcrypto/libssl into the 64-bit perl process when CA.pl is invoked.
> This causes failure on Solaris 10, but seems to be ignored on Solaris 11.
>
> There was specific support to handle 64-bit builds in shlib_wrap, this
> method also needs to be used for 32-bit builds.
>
> This patch makes it work in all cases for me.
> Someone using SPARC should review what /usr/bin/file
> reports for an old 32-bit SPARC library (if such still exists)
> I have no access to SPARC hardware.

% /usr/bin/file /lib/libc.so.1

/lib/libc.so.1: ELF 32-bit MSB dynamic lib SPARC32PLUS Version 1, V8+
Required, dynamically linked, not stripped, no debugging information
available

% /usr/bin/file /lib/sparcv9/libc.so

/lib/sparcv9/libc.so:   ELF 64-bit MSB dynamic lib SPARCV9 Version 1,
dynamically linked, not stripped, no debugging information available

This was on Solaris 10 Sparc.

Regards,

Rainer

> *** shlib_wrap.sh       Tue Feb 16 23:55:51 2016
> --- /usr/local/src/openssl-1.1//shlib_wrap.sh   Tue Mar  1 23:21:23 2016
> ***************
> *** 27,32 ****
> --- 27,37 ----
>                  LD_PRELOAD_64="$LIBCRYPTOSO $LIBSSLSO"; export LD_PRELOAD_64
>                  preload_var=LD_PRELOAD_64
>                  ;;
> +       *ELF\ 32*SPARC*|*ELF\ 32*80386*)
> +               [ -n "$LD_LIBRARY_PATH_32" ] && rld_var=LD_LIBRARY_PATH_32
> +               LD_PRELOAD_32="$LIBCRYPTOSO $LIBSSLSO"; export LD_PRELOAD_32
> +               preload_var=LD_PRELOAD_32
> +               ;;
>          # Why are newly built .so's preloaded anyway? Because run-time
>          # .so lookup path embedded into application takes precedence
>          # over LD_LIBRARY_PATH and as result application ends up linking
>

--
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Reply | Threaded
Open this post in threaded view
|

Re: Solaris 10 80-test_ca failure

Erik Forsberg-11
My patch will work for both solaris versions then.
Can someone commit the fix ?

>-- Original Message --
>
>Am 03.03.2016 um 18:51 schrieb Erik Forsberg:
>>
>> I have been having 32-bit only test failures from test_ca
>> for quite a while now on Solaris 10 (1.1.pre), Finally figured
>> out what is wrong.
>>
>> I build both 32-bit and 64-bit libraries.
>> My /usr/local/bin/perl is always 64-bit,
>> used to be required for assembler support.
>>
>> LD_PRELOAD is used to force newly built libs into the test process
>> using util/shlib_wrap.sh
>>
>> So, when building 32-bit libs, shlib_wrap tries to preload a 32-bit
>> libcrypto/libssl into the 64-bit perl process when CA.pl is invoked.
>> This causes failure on Solaris 10, but seems to be ignored on Solaris 11.
>>
>> There was specific support to handle 64-bit builds in shlib_wrap, this
>> method also needs to be used for 32-bit builds.
>>
>> This patch makes it work in all cases for me.
>> Someone using SPARC should review what /usr/bin/file
>> reports for an old 32-bit SPARC library (if such still exists)
>> I have no access to SPARC hardware.
>
>% /usr/bin/file /lib/libc.so.1
>
>/lib/libc.so.1: ELF 32-bit MSB dynamic lib SPARC32PLUS Version 1, V8+
>Required, dynamically linked, not stripped, no debugging information
>available
>
>% /usr/bin/file /lib/sparcv9/libc.so
>
>/lib/sparcv9/libc.so:   ELF 64-bit MSB dynamic lib SPARCV9 Version 1,
>dynamically linked, not stripped, no debugging information available
>
>This was on Solaris 10 Sparc.
>
>Regards,
>
>Rainer
>
>> *** shlib_wrap.sh       Tue Feb 16 23:55:51 2016
>> --- /usr/local/src/openssl-1.1//shlib_wrap.sh   Tue Mar  1 23:21:23 2016
>> ***************
>> *** 27,32 ****
>> --- 27,37 ----
>>                  LD_PRELOAD_64="$LIBCRYPTOSO $LIBSSLSO"; export LD_PRELOAD_64
>>                  preload_var=LD_PRELOAD_64
>>                  ;;
>> +       *ELF\ 32*SPARC*|*ELF\ 32*80386*)
>> +               [ -n "$LD_LIBRARY_PATH_32" ] && rld_var=LD_LIBRARY_PATH_32
>> +               LD_PRELOAD_32="$LIBCRYPTOSO $LIBSSLSO"; export LD_PRELOAD_32
>> +               preload_var=LD_PRELOAD_32
>> +               ;;
>>          # Why are newly built .so's preloaded anyway? Because run-time
>>          # .so lookup path embedded into application takes precedence
>>          # over LD_LIBRARY_PATH and as result application ends up linking
>>
>
>--
>openssl-dev mailing list
>To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

--
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev