zlib 1.2.12 fails to compile

[ncopa]

When updating alpine linux to 1.2.12 I got this compile error:

gcc -O -D_LARGEFILE64_SOURCE=1 -o example64 example64.o -L. libz.a
gcc -O -D_LARGEFILE64_SOURCE=1 -o minigzip64 minigzip64.o -L. libz.a
/usr/lib/gcc/x86_64-alpine-linux-musl/9.3.0/../../../../x86_64-alpine-linux-musl/bin/ld: deflate.lo: relocation R_X86_64_PC32 against symbol `_length_code' can not be used when making a shared object; recompile with -fPIC
/usr/lib/gcc/x86_64-alpine-linux-musl/9.3.0/../../../../x86_64-alpine-linux-musl/bin/ld: final link failed: bad value

I can work around it by adding -fPIC, but I wonder if that is the correct fix?

There seems also to be a few new symbols introduced in the shared library libz.so.1.2.12:

0000000000010bca T _fini
0000000000003000 T _init
000000000000dbe0 T _tr_align
000000000000dbd0 T _tr_flush_bits
000000000000dcd0 T _tr_flush_block
000000000000d980 T _tr_init
000000000000da80 T _tr_stored_block
000000000000e3e0 T _tr_tally

Not sure that was intentional or not.

[thesamesam]

Someone reported this downstream in Gentoo too and I think it's a consequence of the misdetection of CC (which in some cases forces a static build even when not requested, and then the rest of the assumptions in the build may not hold). Their report was for a 32-bit multilib build on amd64 though, but the CC issue is going to crop up in lots of configurations.

The rest of the script then cascades down a bad path because it's convinced it's not GCC or a GCC-like compiler.

Does #607 help?

It might be another issue of course though.

[ncopa]

Yes, #607 also solves both the -fPIC compile error and the introduction of the new symbols.

[heirecka]

Yeah, I saw that too on a plain x86_64 system which does set CC. And #607 does indeed help.

[madler]

See 05796d3 .