Re: Openssl binary with statically linked libssl and libcrypto

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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 <kevin.lengauer@xxxxxxxxxx> 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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Index of Archives]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Security]     [Bugtraq]     [Linux]     [Linux OMAP]     [Linux MIPS]     [ECOS]     [Asterisk Internet PBX]     [Linux API]

  Powered by Linux