| Summary: | Missing linking against libcrypt on DragonFly | ||
|---|---|---|---|
| Product: | [Unmaintained] kuser | Reporter: | Alex Hornung <alexh> |
| Component: | general | Assignee: | Szombathelyi György <gyurco> |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | CC: | neundorf, rakuco, swildner |
| Priority: | NOR | ||
| Version: | unspecified | ||
| Target Milestone: | --- | ||
| Platform: | Compiled Sources | ||
| OS: | Other | ||
| Latest Commit: | Version Fixed In: | 4.7.4 | |
| Sentry Crash Report: | |||
|
Description
Alex Hornung
2010-08-13 11:27:49 UTC
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). |