Re: [lmi] Building shared zlib

[Greg Chicares]

On 2016-07-15 21:11, Vadim Zeitlin wrote:
> 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

Well, it's good to know that I could figure it out myself, more or less.

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

I might not have figured that out on my own. It's much nicer to make
that command succeed, so that I don't have to worry about where the
object files are in order to link them outside zlib's 'Makefile'.

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

There's no VERSIONINFO in lmi's 'skeleton.dll' or the xmlsoft.org
libraries that we build. I had to check them to be sure, so I guess
I've never sought such information in all these decades.

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

I was wondering why autotools just work for a large library like wx,
or a moderate-sized library like libxml2, while a tiny library like
libz has serious problems.

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

Then (2) is the path I'll follow.