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