On Tue December 27 2011, Michael S. Zick wrote: > On Tue December 27 2011, Michael S. Zick wrote: > > On Tue December 27 2011, Jakob Bohm wrote: > > > On 12/26/2011 1:31 AM, Michael S. Zick wrote: > > > > On Sun December 25 2011, jb-open...@wisemo.com wrote: > > > >> Merry Christmas, and thanks to Michael for pointing out a GNU gcc/ld > > > >> specific > > > >> option to do this in manually written Makefiles. > > > >> > > > >> My replies below are about how to achieve this without GNU specific > > > >> options > > > >> and without having to edit the Configure and Makefiles. These answers > > > >> do > > > >> not apply to Windows, OS/2, DOS and other non-POSIX based build > > > >> environments. > > > >> > > > >> On 24-12-2011 05:31, grarpamp wrote: > > > >>>> 1. Make sure there is a libz.a in /lib or /usr/lib, otherwise you > > > >>>> have no > > > >>>> static zlib to link in. > > > >>> Of course there's an old libz.a there. And it should not matter as > > > >>> we're given the --with-zlib arguments to point the build elsewhere > > > >>> for those libraries. And as seen in the report, it is following those > > > >>> pointers. It's just not using them correctly regarding being told to > > > >>> link against libz.a, not libz.so, with the 'zlib' parameter to config. > > > >> If you pass Configure and option to look for zlib in an additional > > > >> directory, all of these steps apply to that directory too. > > > >>>> 2. Temporarily remove or rename the symlink named exactly "libz.so" > > > >>>> in > > > >>>> /lib, /usr/lib, /usr/local/lib and /zlib125/lib (This ensures it > > > >>>> cannot > > > >>>> link to the dynamic zlib). > > > >>> No, this appears to be to be a ./config build parameter setup > > > >>> error. Why should user's break their perfectly sound systems > > > >>> in order to work around a bug? If users wanted it to link dynamically > > > >>> against libz, they would have specified 'zlib-dynamic' to ./config. > > > >> As partly explained by Michael, there is no portable option that > > > >> ./config could tell the Makefile to pass to the compiler/linker to > > > >> get the desired effect. It simply hasn't got a chance. > > > >> > > > >> Michael's other suggestion to first use the linker to produce and > > > >> intermediary .o file with some unresolved externals is not portable > > > >> either, as only some linkers have the ability to do that. > > > >> > > > >> However a general way to achieve this on almost any UNIX/POSIX > > > >> based system is to artificially present the linker with a scenario > > > >> where the linker thinks there is no shared library version of zlib > > > >> available, only a PIC-compiled static libz.a, which the linker will > > > >> then have to use when creating an OpenSSL shared library. > > > >> > > > >> This is achieved by temporarily hiding the libz.so -> libz.so.N > > > >> symlinks that the linker uses, but keeping the > > > >> libz.so.N -> libz.so.N.N.N symlinks used by the dynamic linker > > > >> on your working computer. > > > >> > > > > *nix base systems (the few I know of anyway) use some variation on > > > > a ld.so.* to do the dynamic linking. > > > > As part of that approach, a ld.so.cache is built on the machine with > > > > the dynamic library links pre-resolved. > > > > > > > > You can do whatever you want with the actual links on disk of a > > > > running system, just as long as you don't rebuild the ld.so.cache > > > > until they are back into working condition. > > > > > > > > As a general precaution - have the links back to their working > > > > condition before doing: make install > > > > Since the install step of some make files will force a ld.so.cache > > > > rebuild as a 'feature'. ;-) > > > > > > > > Mike > > > Thanks, I was approaching this on a more basic level: > > > > > > > I thought I was agreeing with you. ;-) > > > > My only contribution was the warning that some "make install" > > package steps might run ldconfig as part of the install. > > > > With libz from the current (1.2.5) source: > ./configure --prefix=<whatever> --static > > Only builds the static archive but the makefile is broke > for installing only a static archive. (Oops) > > ./configure --perfix=<whatever> > > Builds both the static and the dynamic libraries. > __BUT__ > The "make install" also gratuitously runs ldconfig with all > output directed to /dev/null so your only clue is when > your ld.so.cache turns to trash. ;-) > > That can be avoided by: > $ sudo make install LDCONFIG=false > > - - - - > > And answering my own question, why we haven't heard from > the authors - > They are waiting for one of us to read the directions. ;-) > > It reads to me as if the OpenSSL archive is already setup > to handle this situation, with: no-zlib-dynamic option. > > Will try that one myself next. >
This is what I tried, with the result that the Makefile and generated opensslconf.h files looked reasonable, but... (with a bit of \ added for the m.l.:) $ ./config no-zlib-dynamic zlib \ -DZLIB_INCLUDE=/opt/zlib125/include \ -DLIBZLIB=/opt/zlib125/lib \ shared --prefix=/opt/ssl100e \ --openssldir=/opt/ssl100e/openssl $ make test - - - snip - - - ALL TESTS SUCCESSFUL. make[1]: Leaving directory `/Builds/BLDS/openssl-1.0.0e/test' OPENSSL_CONF=apps/openssl.cnf util/opensslwrap.sh version -a OpenSSL 1.0.0e 6 Sep 2011 built on: Tue Dec 27 10:58:36 CST 2011 platform: linux-x86_64 options: bn(64,64) rc4(1x,char) des(idx,cisc,16,int) idea(int) blowfish(idx) compiler: gcc -fPIC -DOPENSSL_PIC -DZLIB -DOPENSSL_THREADS -D_REENTRANT \ -DDSO_DLFCN -DHAVE_DLFCN_H -DZLIB_INCLUDE=/opt/zlib125/include \ -DLIBZLIB=/opt/zlib125/lib -Wa,--noexecstack -m64 -DL_ENDIAN -DTERMIO \ -O3 -Wall -DMD32_REG_T=int -DOPENSSL_IA32_SSE2 -DOPENSSL_BN_ASM_MONT \ -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DMD5_ASM -DAES_ASM -DWHIRLPOOL_ASM OPENSSLDIR: "/opt/ssl100e/openssl" /Builds/BLDS/openssl-1.0.0e/apps$ ldd openssl linux-vdso.so.1 => (0x00007fff2729d000) libssl.so.1.0.0 => /usr/lib/x86_64-linux-gnu/libssl.so.1.0.0 (0x00007f16e62dc000) libcrypto.so.1.0.0 => /usr/lib/x86_64-linux-gnu/libcrypto.so.1.0.0 (0x00007f16e5f16000) libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007f16e5d11000) libz.so.1 => /usr/lib/libz.so.1 (0x00007f16e5afa000) libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f16e5776000) /lib64/ld-linux-x86-64.so.2 (0x00007f16e6556000) Which certainly looks like it is dynamically linked to the system libz rather than the non-system libz installed in /opt/libz125 Translation: I have to agree with O.P. - It looks broke to me too. ;-) Mike > Mike > > > > Dynamic linking __only__ reads ld.so.cache, so as long as > > nothing (or no one) runs ldconfig - do as you wish with the links. > > > > > On the systems I know about (not many, sorry), ld.so.* and its caching > > > system > > > looks at the symlinks from libz.so.N to libz.so.N.N.N, which is why > > > those symlinks > > > tend to be included in the "runtime" shared library install packages for > > > the system. > > > > > > While /usr/bin/ld (etc.) looks at the libz.so to libz.so.N symlinks to > > > decide which > > > libz.* to link to when the command line says "-lz", which is why those > > > symlinks tend to be included in the "development" library install > > > packages. > > > > > > > Ah, another point I was not clear on: > > > > --start-group <others> libz.a <others> --end-group > > not use the (also allowed): > > --start-group <others> -lz <others> --end-group > > > > The manual only says: "explicit file name(s)" so that might allow > > full pathnames also. > > > > The OP's question was: "How to get OpenSSL build to do this?" > > > > I have not looked at the Makefile myself, I thought one > > of the Makefile authors would post to this thread. > > Maybe it already recognizes a: --libz-static option. > > > > Mike > > > > > > > >> ______________________________________________________________________ > > > >> OpenSSL Project http://www.openssl.org > > > >> User Support Mailing List openssl-users@openssl.org > > > >> Automated List Manager majord...@openssl.org > > > >> > > > >> > > > > ______________________________________________________________________ > > > > OpenSSL Project http://www.openssl.org > > > > User Support Mailing List openssl-users@openssl.org > > > > Automated List Manager majord...@openssl.org > > > > > > > > > > > > ______________________________________________________________________ > > OpenSSL Project http://www.openssl.org > > User Support Mailing List openssl-users@openssl.org > > Automated List Manager majord...@openssl.org > > > > > > > ______________________________________________________________________ > OpenSSL Project http://www.openssl.org > User Support Mailing List openssl-users@openssl.org > Automated List Manager majord...@openssl.org > > ______________________________________________________________________ OpenSSL Project http://www.openssl.org User Support Mailing List openssl-users@openssl.org Automated List Manager majord...@openssl.org