perl5.16 and 5.22 have invalid -lcrypt flag

[cheongi]

perl5.16 and 5.22 build fails.

:info:build 	    perlmini.o opmini.o miniperlmain.o   gv.o toke.o perly.o pad.o regcomp.o dump.o util.o mg.o reentr.o mro.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   -ldl -lm -lcrypt -lutil -lc 
:info:build ld: library not found for -lcrypt
:info:build collect2: ld returned 1 exit status
:info:build ld: library not found for -lcrypt
:info:build collect2: ld returned 1 exit status
:info:build lipo: can't open input file: /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_ports_lang_perl5.16/perl5.16/work/.tmp/cco5fdbS.out (No such file or directory)
:info:build make: *** [miniperl] Error 1

I understand that -lcrypt is meant to be not used on macos. wiki:snc/portfile_dev

Prior versions of perl5 were operating correctly.

(Trying to figure out how to patch the portfile, but not finding it simple...)

[cheongi]

MacOS 10.6.8

[cheongi]

patch to remove -lcrypt flag from makefile

[ryandesign (Ryan Carsten Schmidt)]

I have not heard of this problem before, and the perl ports are in heavy use, which makes me think there is something specific to your computer that is causing this problem.

Please attach the main.log file generated by your failed installation attempt.

If it turns out to be something we need to fix, we should test the other versions of perl too: perl5.8, perl5.10, perl5.12, perl5.14, perl5.18, perl5.20.

[mojca (Mojca Miklavec)]

My configuration step reports

crypt() found.
<crypt.h> NOT found.
crypt_r() NOT found.

and there is no -lcrypt in my Makefile.

Do you have something like /usr/local/lib/libcrypt.dylib or any library like that installed on your computer? Unless this is really specific to 10.6, I suspect that you might have installed some piece of software recently that is now interfering.

[cheongi]

Are you guys saying that this advice on the macports wiki on -lcrypt is wrong?

Dealing with Incompatible Flags

Use a patchfile so that if upstream ever fixes their software to not use -lcrypt and your patch then breaks, you'll be able to tell why.

-lcrypt specifically is a flag you find in some Linux software but which is incompatible with and unnecessary on Mac OS X. If software tries to use that flag on Mac OS X, you would write a patchfile to remove that option, but only apply the patchfile on platform darwin (MacPorts could be installed on a non-Mac operating system and you wouldn't want this particular patch to be applied there). Ideally you would report the problem to the author of the software and they would fix their configure script or whatever, so that Mac users who are not using MacPorts will also benefit from what we discovered and we can remove our patch with the next release.

The error is "library not found". The wiki suggests it is because "library is not needed". The only libcrypt.dylib I have is /opt/local/lib/libcrypt.dylib. No idea why macports says it is not there. I presume it is there because I installed the library trying to get rid of the error.

The error appears to be caused by the unnecessary -lcrypt. What software apart from other macports ports might cause the -lcrypt flag to appear erroneously in my makefile?

I will have to break all the hand-patched ports to regenerate the logs. So if it's not a problem for anybody else, just ignore it and I can keep doing what I am doing.

[mojca (Mojca Miklavec)]

I'm not saying the advice is wrong. All I'm saying is that you are experiencing a different configure/build than the rest of us. I don't get any -lcrypt in my Makefiles. What does

port provides /opt/local/lib/libcrypt.dylib

return?

[cheongi]

$ port provides /opt/local/lib/libcrypt.dylib
/opt/local/lib/libcrypt.dylib is not provided by a MacPorts port.

I do have +universal flag as default since I still have some alive older macs.

[mojca (Mojca Miklavec)]

Replying to ian.cheong@…:

$ port provides /opt/local/lib/libcrypt.dylib
/opt/local/lib/libcrypt.dylib is not provided by a MacPorts port.

Please backup that file just in case, then delete it and run

sudo port clean perl5.22
sudo port install perl5.22

I assume that would work.

Are you able to figure out where this file came from (possibly with help of the timestamp of the file)? In any case, unless the file has been installed by MacPorts, having it there is considered a "bug" on your machine or a "bug" in the software that installed that file to that location, not a bug in MacPorts.

Sometimes "badly designed" software packages put files under /opt/local, but those cases should be reported as problems to distributors of such packages.

One could also argue that Perl should not use libcrypt on Mac at all (I don't know what that library does, so please don't take my words for granted). Honestly I don't know why the configure script first figures out that it should be ok to use that flag and later fails to build. But this is something that you should discuss with upstream Perl developers rather than with MacPorts packagers.

I do have +universal flag as default since I still have some alive older macs.

That should not be relevant in any way.

[cheongi]

perl5.16-mail.log

[cheongi]

So I deleted /opt/local/lib/libcrypt.dylib and everything seems fine. I upp'd the main.log before deleting the file. (It can be deleted.)

OK for perl5.16 and 5.22.

I thought when this problem started, I tested previous perl version which had no problems.

/opt/local/lib/libcrypt.dylib was an alias dated 13/6/2013 to current version of libgcrypt.20.dylib which still exists.

I presume some previous package wrote it???? (I don't mess with /opt.)

[cheongi]

Thanks for you help!

[cheongi]

(FWIW maybe it was gambas which has similar dates.)

[mojca (Mojca Miklavec)]

If I'm looking at the right project: I checked because I wanted to find their binaries for Mac (to check for problems) and noticed that they don't provide any binaries at all. I don't quite understand why they insist in qt4-x11 (that looks like a bad design to me; they could have done with the regular qt4), but there are chances that the software could be provided via MacPorts with some effort. But that's another story / another ticket.

I'm closing the ticket for now. If you figure out any other indication that something is wrong in MacPorts, let us know. (And again, if you manage to figure out where the file came from, let us know as well.)