While trying to track down some problems with some packages, I've come across some odd references in the compiled apps. I'm finding strings like the following in compiled packages - help? /var/tmp/portage/glibc-2.3.3.20040420/work/glibc-2.3.2/buildhere/csu/crti.S /var/tmp/portage/glibc-2.3.3.20040420/work/glibc-2.3.2/csu.G /var/tmp/portage/glibc-2.3.3.20040420/work/glibc-2.3.2/buildhere/csu/crtn.S. /var/tmp/portage/glibc-2.3.3.20040420/work/glibc-2.3.2/csu.GNU The above was pulled out using hexedit against a DBI.so as it was compiled during the perl compile. In fact, the crt libraries that glibc provides also have similar pointers to /var/tmp/portage - this can't be right, can it?
If I don't know what I'm looking at - its ok to tell me :) Like I said (or should have) I'm attempting to track down some anomalous build problems and glibc is a possible candidate (ok, more like I only have 3 candidates and its one of them). The same behaviour as above also shows up in the current ~x86 version.
I'm not sure what your reprting here. The fact that glibc is not fully stripped? The fact that gcc adds stuff to the .note and .comment sections? gcc -v ; for example shows you the exact path where gcc was compiled. Also I've seen a problem crop up on a few PN's like expect which leave a dangling RPATH laying around which point to /var/tmp/foo which is evil as sin.
some of the binaries contain full paths to where they were compiled, so yes, this is normal however, like solar said, if you have something which has RPATH of /var/tmp, then please file a bug
