Force linking to static archives during make?

This should be my last build question.

$ ./auto/configure --with-http_ssl_module …
–with-cc-opt="-I/usr/local/ssl/include"
–with-ld-opt="-L/usr/local/ssl/lib /usr/local/ssl/lib/libssl.a
/usr/local/ssl/lib/libcrypto.a -ldl"

$ make

Results in the following. Note that OpenSSL is still dynamically linked:

$ ldd objs/nginx
linux-vdso.so.1 => (0x00007fffd0dfe000)
libdl.so.2 => /lib64/libdl.so.2 (0x0000003ebf600000)
libpthread.so.0 => /lib64/libpthread.so.0 (0x0000003ebfa00000)
libcrypt.so.1 => /lib64/libcrypt.so.1 (0x0000003ed3e00000)
libpcre.so.1 => /lib64/libpcre.so.1 (0x0000003ec0a00000)
libssl.so.1.0.0 => not found
libcrypto.so.1.0.0 => not found
libz.so.1 => /lib64/libz.so.1 (0x0000003ebfe00000)
libc.so.6 => /lib64/libc.so.6 (0x0000003ebf200000)
/lib64/ld-linux-x86-64.so.2 (0x0000003ebea00000)
libfreebl3.so => /lib64/libfreebl3.so (0x0000003ec7a00000)


Adding -Bstatic does not help even though its clearly on the link
command line:

$ ./auto/configure --with-http_ssl_module …
–with-cc-opt="-I/usr/local/ssl/include" --with-ld-opt="-Bstatic
-L/usr/local/ssl/lib /usr/local/ssl/lib/libssl.a
/usr/local/ssl/lib/libcrypto.a -ldl"

$ make

objs/src/http/modules/ngx_http_upstream_keepalive_module.o
objs/ngx_modules.o
-Bstatic -L/usr/local/ssl/lib /usr/local/ssl/lib/libssl.a
/usr/local/ssl/lib/libcrypto.a -ldl -lpthread -lcrypt -lpcre -lssl
-lcrypto -lz

$ ldd objs/nginx
linux-vdso.so.1 => (0x00007fffd4fc6000)
libdl.so.2 => /lib64/libdl.so.2 (0x0000003ebf600000)

libssl.so.1.0.0 => not found
libcrypto.so.1.0.0 => not found


Omitting -L/usr/local/ssl/lib results in a failed configure.


How does one force nginx to use static linking for a library?

Thanks in advance.

On Tue, Dec 17, 2013 at 04:16:55PM -0500, Jeffrey W. wrote:

Results in the following. Note that OpenSSL is still dynamically linked:
libc.so.6 => /lib64/libc.so.6 (0x0000003ebf200000)
/usr/local/ssl/lib/libcrypto.a -ldl"
linux-vdso.so.1 => (0x00007fffd4fc6000)

How does one force nginx to use static linking for a library?

Thanks in advance.

I can’t tell for Linux, but on FreeBSD it’s as simple as:

$ auto/configure --with-ld-opt=-static
[…]
$ make -sj4
$ file objs/nginx
objs/nginx: ELF 64-bit LSB executable, x86-64, version 1 (FreeBSD),
statically linked, for FreeBSD 9.2 (902503), not stripped
$ ldd objs/nginx
ldd: objs/nginx: not a dynamic ELF executable

Thanks

On Wed, Dec 18, 2013 at 4:29 AM, Ruslan E. [email protected] wrote:

libz.so.1 => /lib64/libz.so.1 (0x0000003ebfe00000)

-L/usr/local/ssl/lib /usr/local/ssl/lib/libssl.a
$ ldd objs/nginx


$ file objs/nginx
objs/nginx: ELF 64-bit LSB executable, x86-64, version 1 (FreeBSD), statically
linked, for FreeBSD 9.2 (902503), not stripped
$ ldd objs/nginx
ldd: objs/nginx: not a dynamic ELF executable
This is a known problem with the toolchains on Linux and Apple. Hence
the reason we need a way to use the fully specified archive when we
want static linking.

In my case, if I distribute on Ubuntu 12.04 LTS, folks will likely get
Ubuntu’s version of OpenSSL since the names are the same and binary
compatible. The Ubuntu folks disable TLSv1.1 and TLSv1.2, and they
refuse to enable them (there’s a bug report covering it).

I just don’t see how this can be done without enhancing/patching
nginx’s configuration subsystem.

Jeff


$ cat t.c
#include <openssl/ssl.h>

int main(int argc, char* argv[])
{
return (int)SSL_library_init();
}

$ gcc -I/usr/local/ssl/include t.c -L/usr/local/ssl/lib -Bstatic -lssl
-lcrypto

$ ldd a.out
linux-vdso.so.1 => (0x00007fff68a2e000)
libssl.so.1.0.0 => not found
libcrypto.so.1.0.0 => not found
libc.so.6 => /lib64/libc.so.6 (0x0000003ebf200000)
/lib64/ld-linux-x86-64.so.2 (0x0000003ebea00000)


$ gcc -I/usr/local/ssl/include t.c /usr/local/ssl/lib/libssl.a
/usr/local/ssl/lib/libcrypto.a -ldl

$ ldd a.out
linux-vdso.so.1 => (0x00007ffffdffe000)
libdl.so.2 => /lib64/libdl.so.2 (0x0000003ebf600000)
libc.so.6 => /lib64/libc.so.6 (0x0000003ebf200000)
/lib64/ld-linux-x86-64.so.2 (0x0000003ebea00000)

Hello!

On Wed, Dec 18, 2013 at 12:03:31PM -0500, Jeffrey W. wrote:


libpcre.so.1 => /lib64/libpcre.so.1 (0x0000003ec0a00000)

/usr/local/ssl/lib/libcrypto.a -ldl -lpthread -lcrypt -lpcre -lssl

$ auto/configure --with-ld-opt=-static
In my case, if I distribute on Ubuntu 12.04 LTS, folks will likely get

$ ldd a.out
linux-vdso.so.1 => (0x00007fff68a2e000)
libssl.so.1.0.0 => not found
libcrypto.so.1.0.0 => not found
libc.so.6 => /lib64/libc.so.6 (0x0000003ebf200000)
/lib64/ld-linux-x86-64.so.2 (0x0000003ebea00000)

Just tested on Ubuntu 13.10, and it seems to work this way:

gcc t.c -I/usr/local/ssl/include -L/usr/local/ssl/lib
-Wl,-Bstatic -lssl -lcrypto -Wl,-Bdynamic -ldl

That is, using

./configure --with-cc-opt="-I/usr/local/ssl/include"
–with-ld-opt="-L/usr/local/ssl/lib -Wl,-Bstatic -lssl -lcrypto
-Wl,-Bdynamic -ldl"

will force use of static versions of libssl and libcrypto, without
any changes to nginx configure.

Alternatively, trivial workaround is to move away dynamic
libraries (or not compile/install them). Or you may ask nginx to
compile OpenSSL for you.


Maxim D.
http://nginx.org/

On Wed, Dec 18, 2013 at 12:03:31PM -0500, Jeffrey W. wrote:

On Tue, Dec 17, 2013 at 04:16:55PM -0500, Jeffrey W. wrote:

Hi there,

How does one force nginx to use static linking for a library?

In my case, if I distribute on Ubuntu 12.04 LTS, folks will likely get
Ubuntu’s version of OpenSSL since the names are the same and binary
compatible. The Ubuntu folks disable TLSv1.1 and TLSv1.2, and they
refuse to enable them (there’s a bug report covering it).

I’d say that it’s not nginx’s job to work around undesired defaults
from Ubuntu.

Invite people to install your OpenSSL package instead, and they’ll be
happy that all of their crypto-using tools have been enhanced.

However, you should be able to build whatever you want to, on your
system.

So…

I just don’t see how this can be done without enhancing/patching
nginx’s configuration subsystem.

It looks to me like you can either try to enhance nginx’s config system
to use a syntax to specify exactly which libraries should be statically
linked and which should be dynamically linked (because restricting this
to just openssl is probably unreasonable)…

Or you can edit your generated objs/Makefile to include exactly the
syntax that your system needs for you to build it the way you want it
to be built.

Perhaps it is as simple as: remove “-lssl -lcrypto”; based on the
examples
you provided.

sed -i ‘/-lssl -lcrypto/s///’ objs/Makefile

(For reference, on a random CentOS system here, I seem to need to use

gcc t.c /usr/lib/libssl.a /usr/lib/libcrypto.a -lkrb5 -lz

to allow it to build cleanly.)

Then build, and distribute your build as widely as the licences allow.

I suspect that if you come up with a general config solution that works
everywhere that matters and avoids obnoxious syntax and doesn’t add to
the maintenance burden, patches will be welcome.

But I also suspect that your use case is quite special, and may not be
worth the effort of a general solution.

(But I’m not going to stop you spending your time however you see fit.)

Good luck with it,

f

Francis D. [email protected]

This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.

| Privacy Policy | Terms of Service | Remote Ruby Jobs