Openssl binary with statically linked libssl and libcrypto

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

Openssl binary with statically linked libssl and libcrypto

K Lengauer
This post was updated on .
Hi all,

I am trying to build the 'openssl' binary with libssl and libcrypto linked
statically because the end product may be used on a system where they are
not available. I recently upgraded to OpenSSL v1.1.1c and previously used
1.0.2s which allowed me to get the 'openssl' binary with statically linked
libssl and libcrypto.

I went through several questions and boards already and tried different
things:
1) Using "no-shared" and "-static" for that matter with ./config is not an
option as I still require the libcrypto.so and libssl.so for some other
tests that are part of the whole component to which OpenSSL belongs in my
use-case.
2) My "solution" so far is to change the "build.info" in /openssl/apps in
the following way:

source:       DEPEND[openssl]=libapps.a ../libssl  
changed to: DEPEND[openssl]=libapps.a ../libssl.a ../libcrypto.a

This way I am able to build both the openssl binary with statically linked
libraries as well as keep building the shared libraries.

However, here comes the catch. In doing so I break several of the OpenSSL
unit tests (notably all 70-* recipe tests such as 70-test_comp.t, etc.) and
they encounter a segmentation fault. I could provide a backtrace of the core
for such a segfault.
If I dont link the libraries statically and instead use the config to point
it to the built .so files the tests run just fine.

Is there a (better) way to achieve my goal to build the 'openssl' binary
with statically linked libcrypto and libssl? I read in a recent question
that statically linking is not recommended but still ask you kindly for any
advice you can give me on this matter.

I am sorry for this lengthy question but I tried to offer some insight in my
thought process so far. Furhter, I apologize if my error is obvious as I am
still learning the topics related to OpenSSL and especially the changes that
occured since OpenSSL v1.1.0.

Regards,
Kevin






--
Sent from: http://openssl.6102.n7.nabble.com/OpenSSL-User-f3.html
Reply | Threaded
Open this post in threaded view
|

Re: Openssl binary with statically linked libssl and libcrypto

Michael Mueller
We are doing this for Linux. See below. Don't recall changing anything related to static build in transition from 1.0.2 to 1.1.1.

For Windows we use the dlls. Noticed that new windows compile creates static libs, so we might convert to using the static libs.

dev@turmeric:/NAS/dev/projectx/OPENSSL/bin/SUSE-Linux> ldd openssl

                linux-vdso.so.1 (0x00007ffe023e4000)

                libdl.so.2 => /lib64/libdl.so.2 (0x00007f551e24e000)

                libpthread.so.0 => /lib64/libpthread.so.0 (0x00007f551e031000)

                libc.so.6 => /lib64/libc.so.6 (0x00007f551dc8a000)

                /lib64/ld-linux-x86-64.so.2 (0x00007f551e452000)

dev@turmeric:/NAS/dev/projectx/OPENSSL/bin/SUSE-Linux> ./openssl version

OpenSSL 1.1.1c  28 May 2019



On Tue, Jul 23, 2019, 5:02 AM K Lengauer <[hidden email]> wrote:
Hi all,

I am trying to build the 'openssl' binary with libssl and libcrypto linked
statically because the end product may be used on a system where they are
not available. I recently upgraded to OpenSSL v1.1.1c and previously used
1.0.2s which allowed me to get the 'openssl' binary with statically linked
libssl and libcrypto.

I went through several questions and boards already and tried different
things:
1) Using "no-shared" and "-static" for that matter with ./config is not an
option as I still require the libcrypto.so and libssl.so for some other
tests that are part of the whole component to which OpenSSL belongs in my
use-case.
2) My "solution" so far is to change the "build.info" in /openssl/apps in
the following way:

source:       DEPEND[openssl]=libapps.a ../libssl 
changed to: DEPEND[openssl]=libapps.a ../libssl.a ../libcrypto.a

This way I am able to build both the openssl binary with statically linked
libraries as well as keep building the shared libraries.

However, here comes the catch. In doing so I break several of the OpenSSL
unit tests (notably all 70-* recipe tests such as 70-test_comp.t, etc.) and
they encounter a segmentation fault. I could provide a backtrace of the core
for such a segfault.
If I dont link the libraries statically and instead use the config to point
it to the built .so files the tests run just fine.

Is there a (better) way to achieve my goal to build the 'openssl' binary
with statically linked libcrypto and libssl? I read in a recent question
that statically linking is not recommended but still ask you kindly for any
advice you can give me on this matter.

I am sorry for this lengthy question but I tried to offer some insight in my
thought process so far. Furhter, I apologize if my error is obvious as I am
still learning the topics related to OpenSSL and especially the changes that
occured since OpenSSL v1.1.0.






--
Sent from: http://openssl.6102.n7.nabble.com/OpenSSL-User-f3.html
Reply | Threaded
Open this post in threaded view
|

Re: Openssl binary with statically linked libssl and libcrypto

K Lengauer
Hi Michael Mueller

Thank you for answering. So if I understand you correctly you also use the
"build.info" file to specify the static libraries as dependencies for the
'openssl' binary.

Do you encounter any segmentation faults when running the tests provided by
OpenSSL in the openssl/test/recipes, i.e. when running "make test"? The
segfaults occur during the category "70" tests, so during ssl/tls tests for
example when testing server - client connections. I only encounter these
segmentation faults when using the static libraries instead of the default
case with shared libs which confuses me a bit.
If you do not encounter these segfaults I guess the error is in my code
extensions (patches, added files). Or can there be another reason?

Regards,
Kevin



--
Sent from: http://openssl.6102.n7.nabble.com/OpenSSL-User-f3.html
Reply | Threaded
Open this post in threaded view
|

Re: Openssl binary with statically linked libssl and libcrypto

Michael Mueller


On Wed, Jul 24, 2019, 7:00 AM K Lengauer <[hidden email]> wrote:

So if I understand you correctly you also use the
"build.info" file to specify the static libraries as dependencies for the
'openssl' binary.

Negative. We use the following method:

./config  \
                no-hw  \
                no-zlib \
                no-shared \
                no-ssl2 \
                no-ssl3 \
                --prefix=$INSTALL_D \
                --openssldir=$INSTALL_D


Do you encounter any segmentation faults when running the tests provided by
OpenSSL in the openssl/test/recipes, i.e. when running "make test"?

Tests run cleanly. Some tests are skipped. 

Reply | Threaded
Open this post in threaded view
|

Re: Openssl binary with statically linked libssl and libcrypto

K Lengauer
I see. Thank you again for answering and for the example ./config arguments.

Sadly, I can not make use of the "no-shared" option as I still need the
shared libraries to be built.

But I wonder if there even is a way to achieve both at the same time.



--
Sent from: http://openssl.6102.n7.nabble.com/OpenSSL-User-f3.html
Reply | Threaded
Open this post in threaded view
|

Re: Openssl binary with statically linked libssl and libcrypto

OpenSSL - User mailing list
>    Sadly, I can not make use of the "no-shared" option as I still need the
    shared libraries to be built.
 
Statically linking against files built for shared libraries is possible on many platforms (link against the .a even though .so exists), but not all platforms.

You can always build twice.

Reply | Threaded
Open this post in threaded view
|

Re: Openssl binary with statically linked libssl and libcrypto

K Lengauer
Hi Rich Salz

Thank you very much for responding and also for the indirect help through
all your posts and comments in posts I read so far when looking for help
with OpenSSL.

Right, that is a good idea. I will try to achieve it by building it twice
such that I can hopefully avoid the errors in the tests. Currently, I am
working on RHEL7 which has not been that picky but I expect on other
platforms it will not be as easy.



--
Sent from: http://openssl.6102.n7.nabble.com/OpenSSL-User-f3.html