lmi
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [lmi] Upgrading libxml2 and libxslt


From: Greg Chicares
Subject: Re: [lmi] Upgrading libxml2 and libxslt
Date: Fri, 15 Jul 2016 21:13:05 +0000
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Icedove/38.8.0

Of course, our messages crossed...

On 2016-07-15 20:19, Vadim Zeitlin wrote:
> On Fri, 15 Jul 2016 18:03:57 +0000 Greg Chicares <address@hidden> wrote:
[...]
> GC> but I still get "No shared library support". I can't understand what
> GC> 'configure' is doing here, but perhaps you can spot the problem easily.
> 
>  Unfortunately this "configure" is, in spite of its name, a manually
> written script and not something generated by autoconf, so it took me some
> time to understand this but I do indeed see what it is doing now and the
> way to work around the problem above is to do the following:
> 
>       % export LDSHARED='gcc -shared'
>       % export LDSHAREDLIBC=''

Oh, so that's what '-lc' meant.

>       % PATH=/MinGW_bin:$PATH ./configure
>       % PATH=/MinGW_bin:$PATH make -s
> 
> This still produces libz.so.1.2.8 and not the expected libz.dll on output
> however. It looks functional and we could just rename it to libz1.dll and
> use it but we'd lose at least the version information from the
> win32/zlib.rc file which doesn't get linked in this case, so, on balance...
> 
> GC> Here is one alternative that seems to work:
> GC> 
> GC> /tmp/zlib-1.2.8[0]$make -f win32/Makefile.gcc
> 
> ... this still seems to be better. The main drawback here is that it strips
> the library, while I'd prefer to keep the symbols, but this is relatively
> minor.

I think I prefer the './configure && make' approach. AFAICT, it doesn't
strip the library, and I don't think I care about embedding version info.

I guess we'll still need a manual step to create a DLL import library,
but that's okay.




reply via email to

[Prev in Thread] Current Thread [Next in Thread]