Version: unspecified (using KDE 4.4.5) OS: other On DragonFly BSD, kuser is not linking against -lcrypt (libcrypt) but it needs to do so to be able to use the crypt() function. I'm not familiar with cmake so I can't provide a patch, but it should be straightforward for anyone with the required knowledge about cmake. For reference, I fixed it manually adding -lcrypt to _KDE_build/kuser/CMakeFiles/kuser.dir/link.txt Reproducible: Always
Linkage with -lcrypt currently depends on crypt.h being found. It is all in kuser/CMakeLists.txt. Does DragonFly provide a crypt.h header?
Hm, actually it seems we don't. Our libcrypt Makefile currently isn't installing crypt.h so it seems that the problem is on our side. I'll have a chat with other developers to see if there's any reason for that; if there isn't I'll fix our Makefile and close this bug. Thanks for your help!
Ok, this is solved now on DragonFly. I've added the crypt.h header to our Makefile so it's installed. Thanks for the help!
Thanks for the investigation. I'm just changing the bug resolution to indicate it was a problem downstream.
Raphael, this doesn't seem right, as FreeBSD doesn't have /usr/include/crypt.h (checked on 6.2 and 8.2). The only header of that name is /usr/include/rpcsvc/crypt.h and that's unrelated. crypt.h doesn't have prototypes for crypt(), crypt_set_format() or crypt_get_format() either (these are in <unistd.h>). Instead it seems to be internal prototypes for the per-algorithm functions (to be set and used from userland by crypt_set_format() and crypt()). At least one pkgsrc package on DragonFly breaks because it assumes that, upon finding /usr/include/crypt.h, the header also provides a prototype for crypt(). So how does KDE really determine if -lcrypt shall be used on FreeBSD?
You are right, the check in kuser is flawed. It only links to libcrypt if crypt.h is found. I've just checked it is solved on FreeBSD by patching the port and always linking to libcrypt. I'll take a look at this.
SVN commit 1261621 by rkcosta: kuser: Properly check whether it must be linked against libcrypt. Systems such as the BSDs do not have crypt.h but do have libcrypt, so we need to check for the library's presence, not the header's. BUG: 247627 FIXED-IN: 4.7.4 M +4 -2 CMakeLists.txt WebSVN link: http://websvn.kde.org/?view=rev&revision=1261621
SVN commit 1261622 by rkcosta: kuser: Properly check whether it must be linked against libcrypt. Systems such as the BSDs do not have crypt.h but do have libcrypt, so we need to check for the library's presence, not the header's. Forward-port of r1261621 to trunk. CCBUG: 247627 M +4 -2 CMakeLists.txt WebSVN link: http://websvn.kde.org/?view=rev&revision=1261622
(In reply to comment #5) > At least one pkgsrc package on DragonFly breaks because it assumes that, upon > finding /usr/include/crypt.h, the header also provides a prototype for crypt(). BTW, which package is that? Do you need any help with it? If so, please mail me so we do not carry on the conversation in this unrelated bug report.
Raphael, thanks for fixing! :) Regarding the pkg: It's all fine. The package (/usr/pkgsrc/chat/dircproxy) will include <unistd.h> as soon as /usr/include/crypt.h is no longer found during configuration (which I'll take care of now).