Summary: | recent changes to gen_usr_ldscript made it a noop on gfbsd | ||
---|---|---|---|
Product: | Gentoo/Alt | Reporter: | Yuta SATOH <nigoro.dev> |
Component: | FreeBSD | Assignee: | Gentoo Toolchain Maintainers <toolchain> |
Status: | RESOLVED FIXED | ||
Severity: | blocker | CC: | bsd+disabled, idarktemplar |
Priority: | Normal | Keywords: | REGRESSION |
Version: | unspecified | ||
Hardware: | All | ||
OS: | FreeBSD | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Bug Depends on: | 417451 | ||
Bug Blocks: | |||
Attachments: | patch for freebsd-lib-9.0-r3.ebuild |
Description
Yuta SATOH
2012-07-25 11:47:09 UTC
see https://bugs.gentoo.org/show_bug.cgi?id=417451#c25 and, no, i dont think we will get rid of this func on g/fbsd (re the comment in the eclass); we do not really care about the /usr move here and will follow upstream too. Created attachment 319216 [details, diff]
patch for freebsd-lib-9.0-r3.ebuild
Check if a directory exists ${D}/lib or ${D}/lib64.
Comment on attachment 319216 [details, diff]
patch for freebsd-lib-9.0-r3.ebuild
no, we need other libs than the libc that we manually move in /lib (ie we need gen_usr_ldscript fixed)
Reproduced on amd64-fbsd. This broke crossdev, catalyst and prevents me from working on improvements to sys-freebsd/freebsd-lib. This deserves blocker importance. (In reply to comment #0) btw, any src_install relying on gen_usr_ldscript to create any particular directories is broken. sounds like freebsd-lib is one such case where it incorrectly assumes /lib64 exists. i've enabled usr ldscripts for freebsd targets again: http://sources.gentoo.org/eclass/toolchain-funcs.eclass?r1=1.113&r2=1.114 *** Bug 428426 has been marked as a duplicate of this bug. *** |