Maybe we can get closer to the problem if you show us the output where Something more significant is going wrong with dynamic libraries later on when I run "make test". If the libraries are not needed, I'm not sure why they are listed in the Makefile.PL. As you are the maintainer of the module, maybe you can tell us why you put the libraries into the Makefile.PL in the first place?

Hi, Corion. Yes, the libraries are all needed. I didn't want to overload the thread with too much information, but after the perl Makefile.PL shown above, the output of make is:

$ make
cp SimpleServer.pm blib/lib/Net/Z3950/SimpleServer.pm
AutoSplitting blib/lib/Net/Z3950/SimpleServer.pm (blib/lib/auto/Net/Z3
+950/SimpleServer)
cp logging-server.pl blib/lib/Net/Z3950/logging-server.pl
cp grs_test.pl blib/lib/Net/Z3950/grs_test.pl
cp OID.pm blib/lib/Net/Z3950/OID.pm
cp GRS1.pm blib/lib/Net/Z3950/GRS1.pm
cp ztest.pl blib/lib/Net/Z3950/ztest.pl
Running Mkbootstrap for SimpleServer ()
chmod 644 "SimpleServer.bs"
"/usr/bin/perl" -MExtUtils::Command::MM -e 'cp_nonempty' -- SimpleServ
+er.bs blib/arch/auto/Net/Z3950/SimpleServer/SimpleServer.bs 644
"/usr/bin/perl" "/System/Library/Perl/5.30/ExtUtils/xsubpp"  -typemap 
+'/System/Library/Perl/5.30/ExtUtils/typemap'  SimpleServer.xs > Simpl
+eServer.xsc
mv SimpleServer.xsc SimpleServer.c
cc -c  -I/usr/local/Cellar/yaz/5.34.0_2/include -DYAZ_POSIX_THREADS=1 
+-DYAZ_HAVE_XML2=1 -DYAZ_HAVE_XSLT=1 -DYAZ_HAVE_EXSLT=1 -g -pipe -DPER
+L_USE_SAFE_PUTENV -Os   -DVERSION=\"1.28\" -DXS_VERSION=\"1.28\"  -iw
+ithsysroot "/System/Library/Perl/5.30/darwin-thread-multi-2level/CORE
+"   SimpleServer.c
rm -f blib/arch/auto/Net/Z3950/SimpleServer/SimpleServer.bundle
LD_RUN_PATH="/usr/local/Cellar/yaz/5.34.0_2/lib" cc  -bundle -undefine
+d dynamic_lookup  SimpleServer.o  -o blib/arch/auto/Net/Z3950/SimpleS
+erver/SimpleServer.bundle  \
       -L/usr/local/Cellar/yaz/5.34.0_2/lib -lyaz_server -lyaz   \
      
ld: warning: -undefined dynamic_lookup may not work with chained fixup
+s
chmod 755 blib/arch/auto/Net/Z3950/SimpleServer/SimpleServer.bundle
Manifying 2 pod documents
[download]

So the issue potential here is if course the -undefined dynamic_lookup warning. Again, at the time it seems benign. And it's not clear whether it's related to the "mostly harmless" warnings, but obvious both pertain to linking.

And after that, we come to the real problem, which manifests during make test (and which you can see is again to do with the linker):

$ make test
"/usr/bin/perl" -MExtUtils::Command::MM -e 'cp_nonempty' -- SimpleServ
+er.bs blib/arch/auto/Net/Z3950/SimpleServer/SimpleServer.bs 644
PERL_DL_NONLAZY=1 "/usr/bin/perl" "-Iblib/lib" "-Iblib/arch" test.pl
1..4
Can't load 'blib/arch/auto/Net/Z3950/SimpleServer/SimpleServer.bundle'
+ for module Net::Z3950::SimpleServer: dlopen(blib/arch/auto/Net/Z3950
+/SimpleServer/SimpleServer.bundle, 0x0002): tried: 'blib/arch/auto/Ne
+t/Z3950/SimpleServer/SimpleServer.bundle' (relative path not allowed 
+in hardened program) at /System/Library/Perl/5.30/darwin-thread-multi
+-2level/DynaLoader.pm line 197.
� at test.pl line 11.
Compilation failed in require at test.pl line 11.
BEGIN failed--compilation aborted at test.pl line 11.
not ok 1
make: *** [test_dynamic] Error 2
[download]

That "relative path not allowed" actually prevents the tests from running, and my real question is, why is this a hardened program at all? My favoured solution would be to not have the program hardened while I'm working on it!

Anyway: I can force this to work my modifying the Makefile.PL to use an absolute path for the ARCHLIB:

sub MY::postamble { 'INST_ARCHLIB = `pwd`/blib/arch' }
[download]

which makes the -I argument absolute. Then the tests run OK (which proves that the "mostly harmless" warnings really were mostly harmless: the necessary libraries were loaded OK for the tests.)

But that "solution" is no good, not only because it's horribly inelegant and knows too much about what ExtUtils::MakeMaker is doing, but more significantly because it prevents make install from working.

This might be a stupid question, but are the development-packages (=header files) also installed? I don't know about MacOS, but in many if not most Unix/Linux systems, the headers come in extra packages, so as to not clutter the harddisks of the average consumer.

Sorry, I should have been clearer about this. Yes, both the headers and the libraries are installed, as is shown by a later successful make test (although I have to go through another bit of detail to make that work — details to follow elsewhere in the thread).