The builtin paludis (cave) functions 'dosym' and 'doins' can't dereference ${D}, nor ${ED}, nor ${T} when called within the ebuilds function multilib_src_install() { .. } Use flags set: dev-libs/boost-1.56.0-r1:0::gentoo Description Boost Libraries for C++ Homepage http://www.boost.org/ Herds cpp Use flags -context -debug doc icu mpi nls python -static-libs threads tools abi_x86: -32 (64) (-x32) python_targets: python2_7 -python3_3 python3_4 build_options: symbols=strip dwarf_compress (-optional_tests) -trace work=tidyup The typical error shown during install phase is: [...] cp "bin.v2/libs/mpi/build/gcc-4.8/gentoorelease/pch-off/threading-multi/libboost_mpi_python-2.7.so.1.56.0" "/var/tmp/paludis/dev-libs-boost-1.56.0-r1/image/usr/lib64/libboost_mpi_python-2.7.so.1.56.0" ln-UNIX /var/tmp/paludis/dev-libs-boost-1.56.0-r1/image/usr/lib64/libboost_mpi_python-2.7.so ln -f -s 'libboost_mpi_python-2.7.so.1.56.0' '/var/tmp/paludis/dev-libs-boost-1.56.0-r1/image/usr/lib64/libboost_mpi_python-2.7.so' common.copy /var/tmp/paludis/dev-libs-boost-1.56.0-r1/image/usr/lib64/mpi.so cp "bin.v2/libs/mpi/build/gcc-4.8/gentoorelease/pch-off/threading-multi/mpi.so" "/var/tmp/paludis/dev-libs-boost-1.56.0-r1/image/usr/lib64/mpi.so" !!! ERROR in dev-libs/boost-1.56.0-r1::gentoo: !!! In /usr/libexec/paludis/utils/dosym at line 29 !!! ${D} not valid; aborting !!! Call stack: !!! * paludis_die_or_error_func (/usr/libexec/paludis/die_functions.bash:67) !!! * main (/usr/libexec/paludis/utils/dosym:29) diefunc: making ebuild PID 10580 exit with error die trap: exiting with error. >>> Running ebuild phases loadenv tidyup as root:root... >>> Starting builtin_loadenv >>> Done builtin_loadenv >>> Starting builtin_tidyup rm -fr /var/tmp/paludis/dev-libs-boost-1.56.0-r1 >>> Done builtin_tidyup >>> Completed ebuild phases loadenv tidyup (MAKEOPTS="-j1" was used in paludis bashrc) I'm unsure about a proper fix - which should be within the package manager, imho - but until then, if you're a paludis user, please find attached patch as a workaround. Greetings, cmuelle8 Reproducible: Always
Created attachment 393134 [details, diff] let boost1.56.0-r1.ebuild build and install using paludis-2.2.0 note that you might not hit this bug if you install boost without the "threads" use flag..
It seems this has a totally different root cause. Paludis was recently built using the gold linker on this system, which apparently breaks quite a bunch of its helper apps: https://sourceware.org/bugzilla/show_bug.cgi?id=16417#c6 Solution to this bug is fixing the corrupt paludis build (that build and installed fine, but does not work). I suggest fixing the paludis ebuild to die if people try to emerge/build it with the gold linker active. Greetings Output of cave info for reference: Package Manager Information: Package Name paludis Package Version 2.2.0 Build Date 2015-01-04T00:36:55+0100 Built with CXX x86_64-pc-linux-gnu-g++ 4.8.4 Built with CXXFLAGS -march=native -pipe -O2 -mfpmath=sse Built with LDFLAGS -march=native -pipe -O2 -mfpmath=sse -Wl,--as-needed -Wl,-O1 -Wl,--hash-style=gnu -Wl,--sort-common Environment Information: Format paludis Config dir /etc/paludis Root / System Root / World file /var/lib/portage/world Repository installed: format vdb location /var/db/pkg builddir /var/tmp/paludis eapi_when_unknown 0 names_cache /var/db/pkg/.cache/names root / Repository installed-unpackaged: format installed_unpackaged location /var/paludis/repositories/installed-unpackaged root / Repository gentoo: format e location /var/paludis/repositories/gentoo builddir /var/tmp/paludis cache /var/paludis/repositories/gentoo/metadata/md5-cache distdir /var/paludis/distfiles eapi_when_unknown 0 eapi_when_unspecified 0 eclassdirs /var/paludis/repositories/gentoo/eclass layout traditional manifest_hashes SHA256 SHA512 WHIRLPOOL names_cache /var/paludis/repositories/gentoo/.cache/names newsdir /var/paludis/repositories/gentoo/metadata/news profile_eapi_when_unspecified 0 profile_layout traditional profiles /var/paludis/repositories/gentoo/profiles/default/linux/amd64/13.0 securitydir /var/paludis/repositories/gentoo/metadata/glsa setsdir /var/paludis/repositories/gentoo/sets sync rsync://rsync.gentoo.org/gentoo-portage sync_options thin_manifests false use_manifest use write_cache /var/paludis/repositories/gentoo/.cache Package information app-shells/bash 4.2_p45 dev-java/java-config 2.2.0 dev-lang/perl 5.20.1-r4 dev-lang/python 2.7.9-r1 3.4.2 dev-util/ccache 3.1.9-r2 dev-util/cmake 3.0.2 dev-util/pkgconfig 0.28-r2 sys-apps/baselayout 2.2 sys-apps/openrc 0.13.6 sys-apps/sandbox 2.6-r1 sys-devel/autoconf 2.13 2.69 sys-devel/automake 1.10.3 1.11.6 1.12.6 1.13.4 1.14 1.4_p6-r1 1.5-r1 1.7.9-r2 1.8.5-r4 1.9.6-r3 sys-devel/binutils 2.24-r3 sys-devel/gcc 4.8.4 sys-devel/gcc-config 1.8 sys-devel/libtool 2.4.4 sys-devel/make 3.82-r4 sys-freebsd/freebsd-lib (none) sys-kernel/linux-headers 3.18 sys-libs/glibc 2.20-r1 sys-libs/uclibc (none)
export D ED T # fix paludis dosym / doins We fix the ebuilds to fix paludis now?
(In reply to Jeroen Roovers from comment #3) > export D ED T # fix paludis dosym / doins > > We fix the ebuilds to fix paludis now? subject line should be changed, as it has nothing to do with paludis in particular. it's just one good example for "gold" linker breakage. there seem to be quite some ebuilds that break if gold is used.. identifying them and adding warnings should be an ongoing effort. cmuelle8
(In reply to cmuelle8 from comment #2) > It seems this has a totally different root cause. Paludis was recently > built using the gold linker on this system, which apparently breaks quite a > bunch of its helper apps: > https://sourceware.org/bugzilla/show_bug.cgi?id=16417#c6 > > Solution to this bug is fixing the corrupt paludis build (that build and > installed fine, but does not work). Reassigned then
Paludis has been removed from the tee.