!!! ERROR: sys-libs/libstdc++-v3-3.3.6 failed. !!! Function dyn_install, Line 1184, Exitcode 0 !!! File /var/tmp/portage/libstdc++-v3-3.3.6/image///usr/lib/debug/usr/lib64/libstdc++-v3/libstdc++.so.5.0.7.debug matches a file type that is not allowed in /usr/lib !!! If you need support, post the topmost build error, NOT this status message. Not sure if this is libstdc++'s fault, splitdebug's fault or multilib-strict's fault so CC'ing everybody.
Apparently splitdebug should be using lib{bitdepth} dirs, so it's out fault. :)
not exactly, it's much more fun. have a look at http://dev.gentoo.org/~plasmaroo/devmanual//archs/amd64/#libdir-links as you can see, it depends upon the selected profile where they go. You probably want to have a look at multilib.eclass too.. @eradicator: adding you since you might be interested in this
Created attachment 75499 [details, diff] Fix location of split-out debug information to comply with FEATURES="multilib-strict" Jason: You proposed to extract the libdir information from the name of the file to be installed. This is problematic: We can't deduce this information from files that end up in {,/usr}/bin, etc. get_libdir() is the only reliable source of information in regard to libdirs. Please consider to apply attached patch.
Created attachment 75503 [details, diff] ebuild-splitdebug-multilib-strict-exempt.patch splitdebug should/can/must not use /lib32/lib64 dirs. It would fundamentally break how it's supposed to work. Try this patch I'm attaching. I believe it's the correct way to solve this.
Actually, with solar we said it shouldn't change anything and always go in /usr/lib. It's also in multilib-strict exempt (I talked with KingTaco when it was committed to trunk). The problem with libstdc++ seems to be that it tries to check for ///usr/lib when exempting it. I've seen this before with another package but I don't remember which.
(In reply to comment #5) > It's also in multilib-strict exempt (I talked with KingTaco when it was > committed to trunk). Where? I dont see it. > The problem with libstdc++ seems to be that it tries to check for ///usr/lib > when exempting it. Are we hitting some regexp thing here?
Look at default-linux/amd64 profiles, it's set in MULTILIB_STRICT_EXEMPT and yeah it's probaly a regexp thingy but I don't know where.
(In reply to comment #7) > Look at default-linux/amd64 profiles, it's set in MULTILIB_STRICT_EXEMPT Ahh.. You said trunk so I was looking at/refering to svn. > and yeah it's probaly a regexp thingy but I don't know where. In ebuild.sh about here I suppose. egrep -v "^${D}/${dir}/${MULTILIB_STRICT_EXEMPT}"
Can somebody test with escaping the ++ please? ebuild.sh: - egrep -v "^${D}/${dir}/${MULTILIB_STRICT_EXEMPT}" + egrep -v "^${D/++/\\+\\+}/${dir}/${MULTILIB_STRICT_EXEMPT}"
I'll give that a try... it's probably that now that you make me think of it, the other package which gave me problem was libsigc++...
Escaping works but is there a way to do it without hardcoding for "++"?
Somebody that uses multilib would have to rewrite the 'egrep -v foo' that was already there. It never would of worked on a pkg containing a ++ in it.
Created attachment 78465 [details, diff] portage-2.1_pre4-multilibstrict.patch Okay this should solve the issue finally. Instead of escaping the input source, I've manipulated the MULTILIB_STRICT_EXEMPT value so that the egrep syntax is converted in standard grep syntax and then changed egrep to grep.
Created attachment 78688 [details, diff] portage-2.1_pre4-multilibstrict.patch (working) Erm sorry the previous one was broken, was the first patch, not the one I was using because I tweaked it after preparing it with quilt. This works.
Released in 2.1_pre5.
