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