| Summary: | app-crypt/rhash: need -lintl when not using glibc (on FreeBSD at least) | ||
|---|---|---|---|
| Product: | Gentoo Linux | Reporter: | Pengcheng Xu <i> |
| Component: | Current packages | Assignee: | Louis Sautier (sbraz) <sbraz> |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | CC: | chewi, grobian, proxy-maint |
| Priority: | Normal | ||
| Version: | unspecified | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
| Attachments: | patch for the 1.3.5 ebuild | ||
|
Description
Pengcheng Xu
2017-08-27 13:00:09 UTC
grobian, you already fixed this issue for Darwin and Solaris. I'm just wondering if there's any particular reason why you check ${CHOST} instead of doing:
use elibc_Darwin || use elibc_SunOS
(In reply to James Le Cuirot from comment #1) > grobian, you already fixed this issue for Darwin and Solaris. I'm just > wondering if there's any particular reason why you check ${CHOST} instead of > doing: > > use elibc_Darwin || use elibc_SunOS That would work too, but some maintainers require that elibc_Darwin and elibc_SunOS are added to IUSE in that case, hence doing the CHOST check is less intrusive to the ebuild. I agree it would feel more precise in this case. While at it, please check, but I remember that !elibc_glibc won't work because musl or uclibc does have intl/iconv, so better be explicit to what systems/libcs don't have it IMO. (In reply to Fabian Groffen from comment #2) > That would work too, but some maintainers require that elibc_Darwin and > elibc_SunOS are added to IUSE in that case, hence doing the CHOST check is > less intrusive to the ebuild. I agree it would feel more precise in this > case. I don't mind the changes but also feel that putting these in IUSE is unnecessary. I asked on IRC and was initially told that libc-specific behaviour should be visible to the user but this turned out to be a bogus reason as these flags are explicitly hidden. > While at it, please check, but I remember that !elibc_glibc won't work > because musl or uclibc does have intl/iconv, so better be explicit to what > systems/libcs don't have it IMO. Agreed, I added all the BSDs explicitly instead, including DragonFly. |