[MacPorts] #53446: perl5.24: build failure when cryptlib is active

[MacPorts]

#53446: perl5.24: build failure when cryptlib is active
-----------------------+----------------------
  Reporter:  posita    |      Owner:  mojca
      Type:  defect    |     Status:  assigned
  Priority:  Normal    |  Milestone:
 Component:  ports     |    Version:  2.4.0
Resolution:            |   Keywords:
      Port:  perl5.24  |
-----------------------+----------------------

Comment (by mojca):

 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 `libcrypt` 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 `libcrypt` 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 `libcrypt` should be used, fix the build system to actually use it
 * find a way to explicitly enable or disable building against `libcrypt`
 with some flag (at the moment we have opportunistic building)

 We could:
 * mark an unconditional build conflict with `libcrypt`
 * depend on `libcrypt`, 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
 `libcrypt`, but a proper solution should be implemented.

 Please correct me if you think my observations are wrong.

--
Ticket URL: <https://trac.macports.org/ticket/53446#comment:6>
MacPorts <https://www.macports.org/>
Ports system for macOS