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
