perl5.24: build failure when cryptlib is active

[posita (Matt Bogosian)]

main.log attached, but here's the relevant section:

:debug:build Executing command line:  cd "/{{PREFIX}}/var/macports/build/_{{PREFIX}}_var_macports_sources_rsync.macports.org_release_tarballs_ports_lang_perl5/perl5.24/work/perl-5.24.0" && /usr/bin/make -j4 -w all
:info:build make: Entering directory `/{{PREFIX}}/var/macports/build/_{{PREFIX}}_var_macports_sources_rsync.macports.org_release_tarballs_ports_lang_perl5/perl5.24/work/perl-5.24.0'
:info:build unset LIBRARY_PATH && /usr/bin/clang -mmacosx-version-min=10.9  -Wl,-headerpad_max_install_names -arch x86_64 -fstack-protector -force_flat_namespace -o miniperl \
:info:build         opmini.o perlmini.o  gv.o toke.o perly.o pad.o regcomp.o dump.o util.o mg.o reentr.o mro_core.o keywords.o hv.o av.o run.o pp_hot.o sv.o pp.o scope.o pp_ctl.o pp_sys.o doop.o doio.o regexec.o utf8.o taint.o deb.o universal.o globals.o perlio.o perlapi.o numeric.o mathoms.o locale.o pp_pack.o pp_sort.o caretx.o dquote.o time64.o  miniperlmain.o  -lcl -lpthread -ldl -lm -lutil -lc
:info:build ld: library not found for -lcl
:info:build clang: error: linker command failed with exit code 1 (use -v to see invocation)
:info:build make: *** [lib/buildcustomize.pl] Error 1
:info:build make: Leaving directory `/{{PREFIX}}/var/macports/build/_{{PREFIX}}_var_macports_sources_rsync.macports.org_release_tarballs_ports_lang_perl5/perl5.24/work/perl-5.24.0'
:info:build Command failed:  cd "/{{PREFIX}}/var/macports/build/_{{PREFIX}}_var_macports_sources_rsync.macports.org_release_tarballs_ports_lang_perl5/perl5.24/work/perl-5.24.0" && /usr/bin/make -j4 -w all
:info:build Exit code: 2

I'm executing this in a prefix build on 10.9.5.

[posita (Matt Bogosian)]

main.log

[mojca (Mojca Miklavec)]

I'm somewhat lost. I don't know where cl comes from and it's not requested when I build Perl myself (neither is this a problem on the buildbots), even though Configure does list it:

libswanted="cl pthread socket bind inet nsl ndbm gdbm dbm db malloc dl ld"
libswanted="$libswanted sun m crypt sec util c cposix posix ucb bsd BSD"

[ryandesign (Ryan Carsten Schmidt)]

This problem just bit me too. It only occurs if the cryptlib port is active when building perl5.24. It could be handled the same way that ImageMagick handles it; see #23354.

[mojca (Mojca Miklavec)]

Thanks a lot for the diagnose, I'll test the proposed solution now.

Did perl5.24.1 add a new dependency or how did everyone manage to be bitten by the same problem at almost the same time? :)

That "workaround" just throws an error and tells the user to deactivate the dependency, right? I guess there's currently no workaround to temporarily disable the port and enable it again after the build? Is the intention of the proposed solution to work flawlessly in trace mode? (Or maybe I'm just wrong and it all works properly already :)

[ryandesign (Ryan Carsten Schmidt)]

Replying to mojca:

Did perl5.24.1 add a new dependency or how did everyone manage to be bitten by the same problem at almost the same time? :)

Most people get binaries. I build from source because I use the universal variant. Maybe others were building from source before binaries for the new version were available.

That "workaround" just throws an error and tells the user to deactivate the dependency, right?

Yes.

I guess there's currently no workaround to temporarily disable the port and enable it again after the build?

Correct, MacPorts base does not have code to do that. I'm not convinced adding code to do that would be the right solution.

Is the intention of the proposed solution to work flawlessly in trace mode? (Or maybe I'm just wrong and it all works properly already :)

I assume using trace mode would avoid the problem.

[mojca (Mojca Miklavec)]

Note that perl explicitly uses -lcl rather than -lCL. I suspect that the problem is in fact "a reverse one".

The build command is as follows:

/usr/bin/clang -mmacosx-version-min=10.7  -Wl,-headerpad_max_install_names -arch x86_64 -fstack-protector -force_flat_namespace -o miniperl opmini.o perlmini.o  gv.o toke.o perly.o pad.o regcomp.o dump.o util.o mg.o reentr.o mro_core.o keywords.o hv.o av.o run.o pp_hot.o sv.o pp.o scope.o pp_ctl.o pp_sys.o doop.o doio.o regexec.o utf8.o taint.o deb.o universal.o globals.o perlio.o perlapi.o numeric.o mathoms.o locale.o pp_pack.o pp_sort.o caretx.o dquote.o time64.o  miniperlmain.o  -lcl -lpthread -ldl -lm -lutil -lc

and fails saying that -lcl wasn't found without actually using -L/opt/local/lib anywhere. On the other hand, when cryptlib is absent, perl doesn't attempt to use that build flag at all. I suspect that there is some test that checks whether the library exists (but does so with some proper LDFLAGS, so that the library visible). But then -L/opt/local/lib is missing when doing the actual compilation.

If I manually change the Makefile and add the library path, the build succeeds and perl then links against /opt/local/lib/libcl.3.4.dylib. Whether or not that's the desired functionality I don't know, but I suspect it is and there's only a problem with missing flags.

When cryptlib is absent, the compilation goes fine. I can add an unconditional

conflicts_build cryptlib

or

if {[file exists ${prefix}/lib/libcl.dylib]} {
    conflicts_build cryptlib
}

Now I finally understand the patch in ImageMagick. That one tests for libCL.dylib (different case). This will only return true on a case-insensitive system. On a case-sensitive system the conflict won't be added.

There are two things that need to be done:

• when cryptlib should be used, fix the build system to actually use it
• find a way to explicitly enable or disable building against cryptlib with some flag (at the moment we have opportunistic building)

We could:

• mark an unconditional build conflict with cryptlib
• depend on cryptlib, fix the build and always link against it (but then people will run into problems when building ImageMagick which is something we probably want to avoid)
• introduce a variant to switch that on and off (but nobody requested that functionality so far)

The easiest workaround is probably to introduce a build conflict with cryptlib, but a proper solution should be implemented.

Please correct me if you think my observations are wrong.

[ryandesign (Ryan Carsten Schmidt)]

I think you've got it.

If there were a flag to tell perl to not use libcl that would be great. If not, maybe the build system could be patched to not look for it. If not, then conflicts_build.

[mojca (Mojca Miklavec)]

Please take a look at ​https://github.com/macports/macports-ports/pull/292.

[mojca (Mojca Miklavec)]

In 8cc7b621/macports-ports:

perl5: avoid opportunistic linking with cryptlib

When cryptlib is installed, perl would use -lcl
and initially fail to build due to a missing -L${prefix}/lib,
but even if this was fixed, it would opportunistically link
against ${prefix}/lib/libcl.dylib.

Another patch that removed linking against bind9
was merged in the same patch file.

Closes: #53446

[mojca (Mojca Miklavec)]

In 8cc7b621/macports-ports:

perl5: avoid opportunistic linking with cryptlib

When cryptlib is installed, perl would use -lcl
and initially fail to build due to a missing -L${prefix}/lib,
but even if this was fixed, it would opportunistically link
against ${prefix}/lib/libcl.dylib.

Another patch that removed linking against bind9
was merged in the same patch file.

Closes: #53446