toolchain-funcs.eclass has recently changed. Currently, freebsd-lib can not be installed. http://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-x86/eclass/toolchain-funcs.eclass?r1=1.112&r2=1.113 Reproducible: Always Steps to Reproduce: 1. emerge --sync 2. cd /usr/portage/sys-freebsd/freebsd-lib 3. ebuild freebsd-lib-9.0-r3.ebuild clean 4. ebuild freebsd-lib-9.0-r3.ebuild install Actual Results: <snip> ===> doc (install) install -d /var/tmp/portage/sys-freebsd/freebsd-lib-9.0-r3/image//usr/share/info install-info --quiet --section="Programming & development tools." --entry="* Regex: (regex). Regular expression library." regex.info /var/tmp/portage/sys-freebsd/freebsd-lib-9.0-r3/image//usr/share/info/dir install -o root -g wheel -m 444 regex.info /var/tmp/portage/sys-freebsd/freebsd-lib-9.0-r3/image//usr/share/info mv: rename /var/tmp/portage/sys-freebsd/freebsd-lib-9.0-r3/image//usr/lib64/libc.so.7 to /var/tmp/portage/sys-freebsd/freebsd-lib-9.0-r3/image//lib64/: No such file or directory * ERROR: sys-freebsd/freebsd-lib-9.0-r3 failed (install phase): * (no error message) * * Call stack: * ebuild.sh, line 85: Called src_install * environment, line 2972: Called gen_libc_ldscript 'lib64' 'usr/lib64' 'usr/lib64' * environment, line 1580: Called die * The specific snippet of code: sed: 4: "# When we get to the li ...": extra characters at the end of q command * * If you need support, post the output of `emerge --info '=sys-freebsd/freebsd-lib-9.0-r3'`, * the complete build log and the output of `emerge -pqv '=sys-freebsd/freebsd-lib-9.0-r3'`. * The complete build log is located at '/var/tmp/portage/sys-freebsd/freebsd-lib-9.0-r3/temp/build.log'. * The ebuild environment file is located at '/var/tmp/portage/sys-freebsd/freebsd-lib-9.0-r3/temp/environment'. * Working directory: '/var/tmp/portage/sys-freebsd/freebsd-lib-9.0-r3/work/etc' * S: '/var/tmp/portage/sys-freebsd/freebsd-lib-9.0-r3/work/lib'
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. ***
