Bug 66047 – glibc pointers to var crop up in compiled .so's

• Product: Gentoo Linux
• Status: RESOLVED INVALID

[Description Michael Cummings (RETIRED) 2004-10-01 10:12:29 UTC]

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?

[Comment 1 Michael Cummings (RETIRED) 2004-10-02 10:13:47 UTC]

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.

[Comment 2 solar (RETIRED) 2004-10-02 12:17:29 UTC]

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.

[Comment 3 SpanKY 2005-02-22 19:54:45 UTC]

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