Re: [lmi] Building shared zlib

[Vadim Zeitlin]

On Fri, 15 Jul 2016 21:04:16 +0000 Greg Chicares <address@hidden> wrote:

GC> Here's where that "No shared library support" message comes from
GC> in 'configure.log':
... skip debugging ...

 Sorry, looks like our messages have crossed and you spent some time
debugging the problems I had already debugged, please see mine at

        http://lists.nongnu.org/archive/html/lmi/2016-07/msg00022.html

if you still haven't received it. I think it answers the remaining
questions:

GC> What's '-lc', a standard *nix C RTL? Anyway, if I run that command
GC> manually, omitting '-lc':

 To avoid running it manually you need to define LDSHAREDLIBC (as nothing).

GC> then it produces something that looks like it might be usable if I
GC> rename it:
GC> 
GC> ls -l libz.so.1.2.8

 It is usable, but lacks version information from win32/zlib.rc.

GC> Where do we go from here?
GC>  (1) Use './configure && make' and fix up the problems manually?
GC>  (2) Try to fix the autotoolization problem?

 As an aside, this is how autotools undeservedly get bad reputation :-( The
problem is that zlib has decided _not_ to use them, hence all this
weirdness.

GC>  (3) Use the msw-specific makefile provided by zlib?
GC>  (4) Just use the zlib.org msw binaries?
GC> I rate those options 2 > 4 > 1 > 3 iff (2) is easy (it's not easy for me),
GC> or 4 > 2 > 1 > 3 otherwise. If we're stuck with an msw-specific solution,
GC> then 4 >>> 3 because it's less work and less prone to error. I think I'll
GC> proceed with (4) provisionally; if (2) is feasible, we can switch to it.

 My personal preference is still (3) for the same reasons as stated before
(to recap: if we build some third party libraries, let's build all of them)
and I don't see any real drawbacks to it. (2) is easy if you agree to not
have the version information in the generated DLL, otherwise it isn't.

 Regards,
VZ