Tests fail on macOS using SSL - need better paths in the .bundle

[briandfoy]

I've found the root of the problem, but I don't have a fix.

I installed DBD::Pg with cpan on v5.30.2 (perl -V at end) with the Postgres pre-built package for macOS. I had set POSTGRES_LIB:

$ export POSTGRES_LIB="/Library/PostgreSQL/12/lib -lssl -lcrypto"

The compilation works fine, but the tests fail because it cannot load the libraries:

$ make test
"/usr/local/perls/perl-5.30.2/bin/perl" -MExtUtils::Command::MM -e 'cp_nonempty' -- Pg.bs blib/arch/auto/DBD/Pg/Pg.bs 644
PGINITDB="/Library/PostgreSQL/12/bin/initdb" PERL_DL_NONLAZY=1 "/usr/local/perls/perl-5.30.2/bin/perl" "-MExtUtils::Command::MM" "-MTest::Harness" "-e" "undef *Test::Harness::Switches; test_harness(0, 'blib/lib', 'blib/arch')" t/*.t
t/00_signature.t ....... skipped: Set the environment variable TEST_SIGNATURE to enable this test
t/00basic.t ............ 1/3
#   Failed test 'use DBD::Pg;'
#   at t/00basic.t line 17.
#     Tried to use 'DBD::Pg'.
#     Error:  Can't load '/Users/brian/.cpan/build/DBD-Pg-3.11.1-2/blib/arch/auto/DBD/Pg/Pg.bundle' for module DBD::Pg: dlopen(/Users/brian/.cpan/build/DBD-Pg-3.11.1-2/blib/arch/auto/DBD/Pg/Pg.bundle, 2): Library not loaded: libssl.1.1.dylib
#   Referenced from: /Users/brian/.cpan/build/DBD-Pg-3.11.1-2/blib/arch/auto/DBD/Pg/Pg.bundle
#   Reason: image not found at /usr/local/perls/perl-5.30.2/lib/5.30.2/darwin-2level/DynaLoader.pm line 197.
#  at t/00basic.t line 17.
# Compilation failed in require at t/00basic.t line 17.
# BEGIN failed--compilation aborted at t/00basic.t line 17.
# CCFLAGS: q[-fno-common -DPERL_DARWIN -mmacosx-version-min=10.15 -fno-strict-aliasing -pipe -fstack-protector-strong -I/usr/local/include -DPERL_USE_SAFE_PUTENV -DPGLIBVERSION=120002 -DPGDEFPORT=5432]
# INC: q[-I/Library/PostgreSQL/12/include -I/usr/local/perls/perl-5.30.2/lib/site_perl/5.30.2/darwin-2level/auto/DBI]
# LIBS: [q[-L/Library/PostgreSQL/12/lib -lssl -lcrypto -lpq -lm]]
# If the error mentions libpq.so, please see the troubleshooting section of the README file
Bailout called.  Further testing stopped:  Cannot continue without DBD::Pg
FAILED--Further testing stopped: Cannot continue without DBD::Pg
make: *** [test_dynamic] Error 255

This is a known problem with macOS's System Integrity Protection, which unsets DYLD_* and LD_*.

Looking at the .bundle file produced, I see that the Pg libraries are names only (not paths or rpaths):

$ otool -L ./blib/arch/auto/DBD/Pg/Pg.bundle
./blib/arch/auto/DBD/Pg/Pg.bundle:
	libssl.1.1.dylib (compatibility version 1.1.0, current version 1.1.0)
	libcrypto.1.1.dylib (compatibility version 1.1.0, current version 1.1.0)
	libpq.5.dylib (compatibility version 5.0.0, current version 5.12.0)
	/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1281.100.1)

I updated the bundle to have absolute paths:

$ install_name_tool -change libssl.1.1.dylib /Library/PostgreSQL/12/lib/libssl.1.1.dylib ./blib/arch/auto/DBD/Pg/Pg.bundle
$ install_name_tool -change libcrypto.1.1.dylib /Library/PostgreSQL/12/lib/libcrypto.1.1.dylib ./blib/arch/auto/DBD/Pg/Pg.bundle
$ install_name_tool -change libpq.5.dylib /Library/PostgreSQL/12/lib/libpq.5.dylib ./blib/arch/auto/DBD/Pg/Pg.bundle

Now the tests work and everyone is happy.

It took me awhile to get to this point, so I haven't even begun to look at the DBD::Pg sources to see where a fix might go in. I'm also hoping someone already knows how to fix this quickly. :)

System details

$ uname -a
Darwin foo.local 19.3.0 Darwin Kernel Version 19.3.0: Thu Jan  9 20:58:23 PST 2020; root:xnu-6153.81.5~1/RELEASE_X86_64 x86_64

$ perl -V
Summary of my perl5 (revision 5 version 30 subversion 2) configuration:
   
  Platform:
    osname=darwin
    osvers=19.3.0
    archname=darwin-2level
    uname='darwin otter.local 19.3.0 darwin kernel version 19.3.0: thu jan 9 20:58:23 pst 2020; root:xnu-6153.81.5~1release_x86_64 x86_64 '
    config_args='-des -Dprefix=/usr/local/perls/perl-5.30.2'
    hint=recommended
    useposix=true
    d_sigaction=define
    useithreads=undef
    usemultiplicity=undef
    use64bitint=define
    use64bitall=define
    uselongdouble=undef
    usemymalloc=n
    default_inc_excludes_dot=define
    bincompat5005=undef
  Compiler:
    cc='cc'
    ccflags ='-fno-common -DPERL_DARWIN -mmacosx-version-min=10.15 -fno-strict-aliasing -pipe -fstack-protector-strong -I/usr/local/include -DPERL_USE_SAFE_PUTENV'
    optimize='-O3'
    cppflags='-fno-common -DPERL_DARWIN -mmacosx-version-min=10.15 -fno-strict-aliasing -pipe -fstack-protector-strong -I/usr/local/include'
    ccversion=''
    gccversion='4.2.1 Compatible Apple LLVM 11.0.0 (clang-1100.0.33.17)'
    gccosandvers=''
    intsize=4
    longsize=8
    ptrsize=8
    doublesize=8
    byteorder=12345678
    doublekind=3
    d_longlong=define
    longlongsize=8
    d_longdbl=define
    longdblsize=16
    longdblkind=3
    ivtype='long'
    ivsize=8
    nvtype='double'
    nvsize=8
    Off_t='off_t'
    lseeksize=8
    alignbytes=8
    prototype=define
  Linker and Libraries:
    ld='cc'
    ldflags =' -mmacosx-version-min=10.15 -fstack-protector-strong -L/usr/local/lib'
    libpth=/usr/local/lib /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/lib/clang/11.0.0/lib /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/lib /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/lib /usr/lib
    libs=-lpthread -ldbm -ldl -lm -lutil -lc
    perllibs=-lpthread -ldl -lm -lutil -lc
    libc=
    so=dylib
    useshrplib=false
    libperl=libperl.a
    gnulibc_version=''
  Dynamic Linking:
    dlsrc=dl_dlopen.xs
    dlext=bundle
    d_dlsymun=undef
    ccdlflags=' '
    cccdlflags=' '
    lddlflags=' -mmacosx-version-min=10.15 -bundle -undefined dynamic_lookup -L/usr/local/lib -fstack-protector-strong'


Characteristics of this binary (from libperl): 
  Compile-time options:
    HAS_TIMES
    PERLIO_LAYERS
    PERL_COPY_ON_WRITE
    PERL_DONT_CREATE_GVSV
    PERL_MALLOC_WRAP
    PERL_OP_PARENT
    PERL_PRESERVE_IVUV
    PERL_USE_SAFE_PUTENV
    USE_64_BIT_ALL
    USE_64_BIT_INT
    USE_LARGE_FILES
    USE_LOCALE
    USE_LOCALE_COLLATE
    USE_LOCALE_CTYPE
    USE_LOCALE_NUMERIC
    USE_LOCALE_TIME
    USE_PERLIO
    USE_PERL_ATOF
  Built under darwin
  Compiled at Mar 15 2020 13:27:13
  %ENV:
    PERL="/Users/brian/bin/perls/perl-latest"
    PERL5_PATH="/Users/brian/bin/perls"
  @INC:
    /usr/local/perls/perl-5.30.2/lib/site_perl/5.30.2/darwin-2level
    /usr/local/perls/perl-5.30.2/lib/site_perl/5.30.2
    /usr/local/perls/perl-5.30.2/lib/5.30.2/darwin-2level
    /usr/local/perls/perl-5.30.2/lib/5.30.2

[turnstep]

Anyone have ideas on this? I do not have a OSX system to test this out on. My internet investigation seems to reveal that disabling System Integrity Protection is not an option, as it requires a reboot, and the only option is to write a shell script that 1) gets run and thus stripped of LD_* and DYLD_* 2) Sets LD_LIBRARY_PATH itself and then 3) runs the actual program. I have no idea how to make all that magic happen via Makefile.PL however.

Seems there must be some other solution, as stripping those ENVs seems so draconian it must be affecting lots of programs, not just little old DBD::Pg.

[briandfoy]

You don't want to use install_name_tool as I showed? I don't have time to work on this right now, but my first goal would be to check that DBD::Pg isn't ignoring some setting in the tool that would put the paths to the libraries in the bundle.

[esabol]

@briandfoy is correct. You need to use install_name_tool as shown above.

[esabol]

https://rt.cpan.org/Public/Bug/Display.html?id=117082 is related.

[briandfoy]

Oh man, had I checked RT and seen that, I would have saved myself a couple days of frustrating work. Always check the bug queues!

[turnstep]

Update the README but unsure of what else to do. Give Makefile.PL a lot of brains so it detects the error and creates a wrapper shell script with the correct ENV vars that calls install_name_tool?

[esabol]

I think the solution is to tweak the Makefile by inserting the install_name_tool commands somewhere in MY::postamble in Makefile.PL if the platform is macOS, but I’m by no means an expert in Perl build mechanisms.

[shmenolin]

I had the exact problem. Updating the bundle files solved it! Thank you very much!

[esabol]

This development seems relevant to this issue:

https://stackoverflow.com/questions/77078167/how-does-one-consistently-set-rpath-on-a-dynamic-library-and-compile-time

The answer, ultimately, is update to the latest ExtUtils::MakeMaker.

As @håkon-hægland points out in his comment on the OP, he's investigated this quite a bit, as documented in ExtUtils-MakeMaker issue #402. A pull request merged in September 2021 was his attempt to address the issue; it was released in v7.64 in December 2021.

Upgrading to the latest version fixed the issue completely, so I was able to remove the call to install_name_tool. Anyone testing on macOS 10.4 or earlier will need v7.66 to avoid the setting of rpath, however.