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