Changes between Initial Version and Version 1 of Ticket #53446, comment 6
- Timestamp:
- Feb 2, 2017, 1:23:17 PM (8 years ago)
Legend:
- Unmodified
- Added
- Removed
- Modified
-
Ticket #53446, comment 6
initial v1 5 5 /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 6 6 }}} 7 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.7 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. 8 8 9 9 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. 10 10 11 When ` libcrypt` is absent, the compilation goes fine. I can add an unconditional11 When `cryptlib` is absent, the compilation goes fine. I can add an unconditional 12 12 {{{ 13 13 conflicts_build cryptlib … … 22 22 23 23 There are two things that need to be done: 24 * when ` libcrypt` should be used, fix the build system to actually use it25 * find a way to explicitly enable or disable building against ` libcrypt` with some flag (at the moment we have opportunistic building)24 * when `cryptlib` should be used, fix the build system to actually use it 25 * find a way to explicitly enable or disable building against `cryptlib` with some flag (at the moment we have opportunistic building) 26 26 27 27 We could: 28 * mark an unconditional build conflict with ` libcrypt`29 * 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)28 * mark an unconditional build conflict with `cryptlib` 29 * 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) 30 30 * introduce a variant to switch that on and off (but nobody requested that functionality so far) 31 31 32 The easiest workaround is probably to introduce a build conflict with ` libcrypt`, but a proper solution should be implemented.32 The easiest workaround is probably to introduce a build conflict with `cryptlib`, but a proper solution should be implemented. 33 33 34 34 Please correct me if you think my observations are wrong.