[lmi] Building shared zlib [Was: Upgrading libxml2 and libxslt]

[Greg Chicares]

On 2016-07-15 18:03, Greg Chicares wrote:
[...]
> /tmp[0]$wget http://zlib.net/zlib-1.2.8.tar.gz
> /tmp[0]$tar -xvf /cache_for_lmi/downloads/zlib-1.2.8.tar.gz
> /tmp[0]$cd zlib-1.2.8
> /tmp/zlib-1.2.8[0]$export PATH="/MinGW_/bin:${PATH}"
> /tmp/zlib-1.2.8[0]$gcc -dumpversion
> 4.9.1
> /tmp/zlib-1.2.8[0]$./configure
> Checking for gcc...
> Checking for shared library support...
> No shared library support.

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

Checking for shared library support...
=== ztest2204.c ===
extern int getchar();
int hello() {return getchar();}
===
gcc -w -c -O3 -fPIC ztest2204.c
-O3 -fPIC -o ztest2204.so ztest2204.o
./configure: line 343: -O3: command not found
(exit code 127)
No shared library support.

Line 343 in 'configure' is a testing function:

    340 try()
    341 {
    342   show $*
    343   ( $* ) >> configure.log 2>&1
    344   ret=$?
    345   if test $ret -ne 0; then
    346     echo "(exit code "$ret")" >> configure.log
    347   fi
    348   return $ret
    349 }

The real problem is on line 386:

    377 # see if shared library build supported
    378 cat > $test.c <<EOF
    379 extern int getchar();
    380 int hello() {return getchar();}
    381 EOF
    382 if test $shared -eq 1; then
    383   echo Checking for shared library support... | tee -a configure.log
    384   # we must test in two steps (cc then ld), required at least on SunOS 
4.x
    385   if try $CC -w -c $SFLAGS $test.c &&
    386      try $LDSHARED $SFLAGS -o $test$shared_ext $test.o; then
    387     echo Building shared library $SHAREDLIBV with $CC. | tee -a 
configure.log
    388   elif test -z "$old_cc" -a -z "$old_cflags"; then
    389     echo No shared library support. | tee -a configure.log
    390     shared=0;
    391   else
    392     echo 'No shared library support; try without defining CC and CFLAGS'
    392  | tee -a configure.log
    393     shared=0;
    394   fi
    395 fi

Specifically, this test:

    385 if try $CC -w -c $SFLAGS $test.c &&
    386 try $LDSHARED $SFLAGS -o $test$shared_ext $test.o; then

produces this output:

    gcc -w -c -O3 -fPIC ztest2204.c
    -O3 -fPIC -o ztest2204.so ztest2204.o
    ./configure: line 343: -O3: command not found

At first I thought that the line to be tested was split, and needed a '\':

    gcc -w -c -O3 -fPIC ztest2204.c \
    -O3 -fPIC -o ztest2204.so ztest2204.o

but actually it seems that '$LDSHARED' is undefined. Specifying a
reasonable value on the command line seems to work:

/opt/lmi/xml-scratch/zlib-1.2.8[0]$LDSHARED='gcc -shared' ./configure

Checking for gcc...

Checking for shared library support...

Building shared library libz.so.1.2.8 with gcc.

Checking for off64_t... Yes.

Checking for fseeko... Yes.

Checking for strerror... Yes.

Checking for unistd.h... Yes.

Checking for stdarg.h... Yes.

Checking whether to use vs[n]printf() or s[n]printf()... using vs[n]printf().

Checking for vsnprintf() in stdio.h... Yes.

Checking for return value of vsnprintf()... Yes.

Checking for attribute(visibility) support... No.


But then 'make' fails to produce a shared library. It starts out okay,
with a series of 'gcc' commands like this:

  gcc -O3  -D_LARGEFILE64_SOURCE=1   -c -o adler32.o adler32.c

but then it tries to do the same thing for each file with '-fPIC',
which I guess is required for *nix, and gets a warning for each:

  gcc -O3  -fPIC -D_LARGEFILE64_SOURCE=1 -DPIC -c -o objs/adler32.o adler32.c
  adler32.c:1:0: warning: -fPIC ignored for target (all code is position 
independent)

...and then it tries (and fails) to link with '-lc':

gcc -shared -O3  -fPIC -D_LARGEFILE64_SOURCE=1 -o libz.so.1.2.8 adler32.lo 
crc32.lo deflate.lo infback.lo inffast.lo inflate.lo inftrees.lo trees.lo 
zutil.lo compress.lo uncompr.lo gzclose.lo gzlib.lo gzread.lo gzwrite.lo  -lc

C:/opt/lmi/MinGW-4_9_1/bin/../lib/gcc/i686-w64-mingw32/4.9.1/../../../../i686-w64-mingw32/bin/ld.exe:
 cannot find -lc


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

$gcc -shared -O3  -fPIC -D_LARGEFILE64_SOURCE=1 -o libz.so.1.2.8 adler32.lo 
crc32.lo deflate.lo infback.lo inffast.lo inflate.lo inftrees.lo trees.lo 
zutil.lo compress.lo uncompr.lo gzclose.lo gzlib.lo gzread.lo gzwrite.lo

then it produces something that looks like it might be usable if I
rename it:

ls -l libz.so.1.2.8

-rwxr-xr-x 1 earl None 138245 Jul 15 20:52 libz.so.1.2.8


Where do we go from here?
 (1) Use './configure && make' and fix up the problems manually?
 (2) Try to fix the autotoolization problem?
 (3) Use the msw-specific makefile provided by zlib?
 (4) Just use the zlib.org msw binaries?
I rate those options 2 > 4 > 1 > 3 iff (2) is easy (it's not easy for me),
or 4 > 2 > 1 > 3 otherwise. If we're stuck with an msw-specific solution,
then 4 >>> 3 because it's less work and less prone to error. I think I'll
proceed with (4) provisionally; if (2) is feasible, we can switch to it.