compress-raw-zlib-pm5* fail tests bigly on macOS11

[nieder]

As mentioned in #682, compress-raw-zlib-pm5* fail tests due to problems with system-zlib (not a real dylib anymore, but in a linker cache)

t/01version.t ...... 1/3 
#     Failed test (t/01version.t at line 23)
#     Tried to use 'Compress::Raw::Zlib'.
#     Error:  Can't load '/opt/sw3/src/fink.build/compress-raw-zlib-pm5184-2.096-1/Compress-Raw-Zlib-2.096/blib/arch/auto/Compress/Raw/Zlib/Zlib.bundle' for module Compress::Raw::Zlib: dlopen(/opt/sw3/src/fink.build/compress-raw-zlib-pm5184-2.096-1/Compress-Raw-Zlib-2.096/blib/arch/auto/Compress/Raw/Zlib/Zlib.bundle, 2): Symbol not found: _adler32
#   Referenced from: /opt/sw3/src/fink.build/compress-raw-zlib-pm5184-2.096-1/Compress-Raw-Zlib-2.096/blib/arch/auto/Compress/Raw/Zlib/Zlib.bundle
#   Expected in: flat namespace
#  in /opt/sw3/src/fink.build/compress-raw-zlib-pm5184-2.096-1/Compress-Raw-Zlib-2.096/blib/arch/auto/Compress/Raw/Zlib/Zlib.bundle at /opt/sw3/lib/perl5-core/5.18.4/darwin-thread-multi-2level/DynaLoader.pm line 194.
#  at (eval 6) line 2.
# Compilation failed in require at (eval 6) line 2.

The failure occurs in both our current C::Z:Raw 2.074 and latest upstream 2.096.
The package builds/tests cleanly if I use the internal zlib code that comes with the package or use a Fink provided zlib (not in dists).

[dmacks]

Does libz (apple's, cached apparently) not have the _adler32 symbol? Does /usr/include/zlib.h declare it (or was there whining at build-time)? IIRC, apple had some chaos with mismatched headers and libs for libz years ago, I hope it's not back to being broken again.

Perl .bundle are dlopen()ed and therefore do not always dyld-link all their dependencies (-undefined dynamic_lookup, or "dyld defer failure until user-land load-time" as pogma used to say). Years ago I looked at using -bundle_loader to allow scrapping that flag (would convert missing symbols to compile-time fail) but never got around to it:(

[nieder]

Compiled this program on 10.13 and 11.0:

#ifdef __cplusplus
extern "C"
#endif
char adler32 ();
int
main ()
{
return adler32 ();
  ;
  return 0;
}

$ cc -o conftest conftest.c -lz
$ otool -L conftest
conftest:
	/usr/lib/libz.1.dylib (compatibility version 1.0.0, current version 1.2.11)
	/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1252.50.4)

If I remove -lz from the compile line, the build fails. Same results if I use inflateCopy instead of adler32

There is no /usr/include on 10.14+. /usr/lib does not have any libz related files on 11.0 $SDK_PATH/usr/include/z*.h have adler32 stuff. $SDK_PATH/usr/lib has a .tbd file that's for zlib1.2.11 (which matches the headers).

[nieder]

This is the 'configure' output from zlib-compress-raw-pm5282:

	ARCHFLAGS="-I/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX11.0.sdk/System/Library/Perl/5.28/darwin-thread-multi-2level/CORE" /usr/bin/arch -x86_64 /usr/bin/perl5.28 Makefile.PL PERL="/usr/bin/arch -x86_64 /usr/bin/perl5.28" PREFIX=/opt/sw3 INSTALLPRIVLIB=/opt/sw3/lib/perl5/5.28.2 INSTALLARCHLIB=/opt/sw3/lib/perl5/5.28.2/darwin-thread-multi-2level INSTALLSITELIB=/opt/sw3/lib/perl5/5.28.2 INSTALLSITEARCH=/opt/sw3/lib/perl5/5.28.2/darwin-thread-multi-2level INSTALLMAN1DIR=/opt/sw3/share/man/man1 INSTALLMAN3DIR=/opt/sw3/share/man/man3 INSTALLSITEMAN1DIR=/opt/sw3/share/man/man1 INSTALLSITEMAN3DIR=/opt/sw3/share/man/man3 INSTALLBIN=/opt/sw3/bin INSTALLSITEBIN=/opt/sw3/bin INSTALLSCRIPT=/opt/sw3/bin INSTALLSITESCRIPT=/opt/sw3/bin
Parsing config.in...
Auto Detect Gzip OS Code..
Setting Gzip OS Code to 3 [Unix/Default]
Looks Good.
Up/Downgrade not needed.
Checking if your kit is complete...
Looks good
Warning (mostly harmless): No library found for -lz
Redundant argument in sprintf at /opt/sw3/lib/perl5/5.28.2/ExtUtils/MM_Unix.pm line 4061.
Generating a Unix-style Makefile

So not finding -lz, but not clear what method it's using. If doing a file check, it will fail. If looking for symbol presence, it should work.

[nieder]

Lastly, I went into the failed directory, added -lz to Makefile::LDDFLAGS, then ran make; make test and it worked. So the failure is in the detection method.

[dmacks]

That comes from EU::MM. Uh...oh...

[nieder]

I tested updating EU::MM to the latest upstream (7.56 vs our 7.44) but no change.

[dmacks]

Could you try creating the following Makefile.PL in an otherwise empty directory:

use ExtUtils::MakeMaker;
WriteMakefile(
  NAME => 'foo',
  LIBS => ['-L/sw/lib -ldb -lnosuch -lz'],
);

then do:

$ touch foo.xs
$ perl Makefile.PL
$ grep LIBS Makefile

replacing "-L/sw/lib -ldb" with your fink prefix and a .dylib that exists. So the libdb.dylib file can be found and can also be linked whereas libnosuch.dylib does not exist and also can't be linked. As I understand it, 'perl Makefile.PL' constructs a Makefile that only contains the -l flags whose actual files could be found. So for my 10.13, I see:
EXTRALIBS = -L/sw/lib -ldf -lz
whereas I suspect you would only see:
EXTRALIBS = -L/sw/lib -ldf

[nieder]

(used -ldb which exists as /opt/sw3/lib/libdb.dylib and -lgmalloc which is a real file in /usr/lib)

[BigSur:~/jnk] nieder $ perl Makefile.PL
Warning (mostly harmless): No library found for -lnosuch
Warning (mostly harmless): No library found for -lz
Generating a Unix-style Makefile
Writing Makefile for foo
Writing MYMETA.yml and MYMETA.json

EXTRALIBS = -L/opt/sw3/lib -ldb -lgmalloc

[dmacks]

Filed as EU::MM bug.

[dmacks]

Reported to be fixed in EU::MM 7.58. Could you try updating our extutils-makemaker-pm* packages and see if that cures it?

[nieder]

On 11.0.1:
Updating extutils-makemaker-pm5282 to 7.58 allows compress-raw-zlib-pm5282 to build.
Having problems testing pm5184 because test-simple-pm5184 (dependency on way to EU::MM) is failing tests:

t/Legacy/exit.t .................................. 236/? Can't load '/opt/sw/lib/perl5/5.18.4/darwin-thread-multi-2level/auto/List/Util/Util.bundle' for module List::Util: dlopen(/opt/sw/lib/perl5/5.18.4/darwin-thread-multi-2level/auto/List/Util/Util.bundle, 0x0002): symbol '_Perl_croak_memory_wrap' not found, expected in flat namespace by '/opt/sw/lib/perl5/5.18.4/darwin-thread-multi-2level/auto/List/Util/Util.bundle' at /System/Library/Perl/5.28/XSLoader.pm line 96.

Same error as above, but this is on the way to building EU::MM. I suppose we could backport upstream's fix to the EU::MM included in perl5*-core ?

[nieder]

hmpf. applying Perl-Toolchain-Gang/ExtUtils-MakeMaker@8b924f6 to Fink's perl5184 didn't fix the test-simple-pm5184 failure.
Neither did Perl/perl5@d296ead which is a separate fix from upstream perl proper.

[nieder]

So the test-simple-pm5184 failure is fixed by installing perl5184 (not just perl5184-core). Same behavior on 10.13 with pm5282. Is that normal? Simple enough to add it to TestDepends (or will it be an actual Depends)?

[nieder]

Now tested all pm variants. EU::MM-7.58 fixes this.