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 at 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 at 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 at adnovum.ch> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20190723/9f31ee1e/attachment.html>