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 > ______________________________________________________________________ > 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
