I'm trying to build hprof from http://download.savannah.nongnu.org/releases/pyprof/hprof-0.1.1.tar.gz This works on my Debian x86 box, but not on my gentoo x86_64 box. I have seen other reports of the same error for different software on gentoo, but no fixes: http://blade.nagaokaut.ac.jp/cgi-bin/scat.rb/ruby/ruby-talk/194965 and http://blade.nagaokaut.ac.jp/cgi-bin/scat.rb/ruby/ruby-talk/195670 http://lists.ximian.com/pipermail/openoffice/2005-August/001104.html http://lists.kde.org/?l=kde-devel&m=112898516904717&w=2 Notice that the error message exhorts us to use -fPIC, when we are already doing so. I have also submitted this bug to the hprof people in the hopes that they can help solve this -- but at this point, I expect that it is a gentoo bug. novalis@novalis /tmp/hprof-0.1.1 $ python setup.py build running build running build_py running build_ext building '_hotshot' extension creating build/temp.linux-x86_64-2.4 creating build/temp.linux-x86_64-2.4/src x86_64-pc-linux-gnu-gcc -pthread -fno-strict-aliasing -DNDEBUG -fPIC -I/usr/include/python2.4 -c src/_hotshot.c -o build/temp.linux-x86_64-2.4/src/_hotshot.o x86_64-pc-linux-gnu-gcc -pthread -shared build/temp.linux-x86_64-2.4/src/_hotshot.o -o build/lib.linux-x86_64-2.4/_hotshot.so /usr/lib/gcc/x86_64-pc-linux-gnu/4.1.1/../../../../x86_64-pc-linux-gnu/bin/ld: warning: creating a DT_TEXTREL in object. /usr/lib/gcc/x86_64-pc-linux-gnu/4.1.1/../../../../x86_64-pc-linux-gnu/bin/ld: build/temp.linux-x86_64-2.4/src/_hotshot.o: relocation R_X86_64_PC32 against `get_tdelta_external' can not be used when making a shared object; recompile with -fPIC /usr/lib/gcc/x86_64-pc-linux-gnu/4.1.1/../../../../x86_64-pc-linux-gnu/bin/ld: final link failed: Bad value collect2: ld returned 1 exit status error: command 'x86_64-pc-linux-gnu-gcc' failed with exit status 1
We don't support stuff that's not in portage tree, report such things upstream.
Gentoo's version of binutils clearly has a bug -- it tells you to "recompile with -fPIC" when -fPIC is already used. The four specific examples I turned up are all demonstrations of the bug in binutils.
Sure, apparent from the wonderful proof that it compiles on x86... Definitely out binutils is broken... Please, review the following before bugging us again about broken upstream code: http://www.gentoo.org/proj/en/base/amd64/howtos/index.xml?part=1&chap=3
And also http://www.gentoo.org/proj/en/hardened/pic-internals.xml
OK, I've read all the docs and my situation doesn't fall under any of the listed cases. Here is a very short test case -- note that removing "inline" makes the compile succeed: x86_64-pc-linux-gnu-gcc -pthread -fno-strict-aliasing -DNDEBUG -fPIC -c foo.c -o foo.o x86_64-pc-linux-gnu-gcc -pthread -shared foo.o -o foo.so foo.c: static inline int frobnicate(int x) { return x + 1; } int refrobnicate(int y) { void *frob = (void *)frobnicate; int (*frob_fn)(int) = frob; return frob_fn(y) + frob_fn(y); }
You can't declare a function as inline and then point at it, because it does not exist as an instance in the code, it's "copy-pasted" into the calling function. This is not a toolchain bug.
(In reply to comment #6) > You can't declare a function as inline and then point at it, because it does > not exist as an instance in the code, it's "copy-pasted" into the calling > function. This is not a toolchain bug. 1. Inline does *not* require that the function be copy-pasted. It's only a hint. Further, the C standard explicitly contemplates external linkage of inline functions (and thus that there might be multiple versions of an inline function). See section 6.7.4 2. Even if C *did* have this rule, the error message generated is totally unhelpful. It should say, "You can't have a function pointer to an inline function." It in fact says something totally incorrect ("recompile with -fPIC").
(In reply to comment #7) > 1. Inline does *not* require that the function be copy-pasted. It's only a > hint. Further, the C standard explicitly contemplates external linkage of > inline functions (and thus that there might be multiple versions of an inline > function). See section 6.7.4 Indeed, it says: 5 A function declared with an inline function specifier is an inline function. The function specifier may appear more than once; the behavior is the same as if it appeared only once. Making a function an inline function suggests that calls to the function be as fast as possible.118) The extent to which such suggestions are effective is implementation-defined.119) Further, http://gcc.gnu.org/onlinedocs/gcc-4.1.0/gcc/Inline.html says: "Inlining of functions is an optimization and it really
(In reply to comment #7) > 1. Inline does *not* require that the function be copy-pasted. It's only a > hint. Further, the C standard explicitly contemplates external linkage of > inline functions (and thus that there might be multiple versions of an inline > function). See section 6.7.4 Indeed, it says: 5 A function declared with an inline function specifier is an inline function. The function specifier may appear more than once; the behavior is the same as if it appeared only once. Making a function an inline function suggests that calls to the function be as fast as possible.118) The extent to which such suggestions are effective is implementation-defined.119) Further, http://gcc.gnu.org/onlinedocs/gcc-4.1.0/gcc/Inline.html says: "Inlining of functions is an optimization and it really works only in optimizing compilation. If you don't use -O, no function is really inline." ...and... "When a function is both inline and static, if all calls to the function are integrated into the caller, and the function's address is never used, then the function's own assembler code is never referenced." That being said, I have seen this with dev-libs/icu-3.4.1. I could work it around there by using -O2 (it disabled the inlining) and the code in question IS used, which makes this whole thing confusing at least.
Ok, Simon and I did some more digging and it looks like a gcc bug. (Oh noes..) Using foo.c as above, compiled .so fine with gcc-3.4.6-r2. With gcc-4.1.1-r1 Fails to create .so with reporters command line, fails with the addition of -fkeep-inline-functions, and fails with -fno-inline. Looking at the objdump -d output for each of the foo.o's with gcc-4.1 they are identical no matter which of these flags is passed (i.e. no frobnicate function). (ditto readelf -s for each of the 4.1.1 objects.) Possibly useful info. duality hprof-0.1.1 # readelf -s foo.o.346 | grep frobnicate 5: 000000000000003e 14 FUNC LOCAL DEFAULT 1 frobnicate 9: 0000000000000000 62 FUNC GLOBAL DEFAULT 1 refrobnicate duality hprof-0.1.1 # readelf -s foo.o.411 | grep frobnicate 8: 0000000000000000 61 FUNC GLOBAL DEFAULT 1 refrobnicate 9: 0000000000000000 0 NOTYPE GLOBAL DEFAULT UND frobnicate (If anyone requires specific objdump, readelf or savetemps output, I can provide it)
Created attachment 99992 [details] pic.i reduced testcase
gcc-4.0.3 and gcc-4.2 work just fine
this has been fixed in gcc-4.1.2, but i dont know if i feel like tracking down the patch that fixed it from 4.1.1 ...
*** Bug 152719 has been marked as a duplicate of this bug. ***
*** Bug 163734 has been marked as a duplicate of this bug. ***
*** Bug 156082 has been marked as a duplicate of this bug. ***
*** Bug 164767 has been marked as a duplicate of this bug. ***
(In reply to comment #13) > this has been fixed in gcc-4.1.2, but i dont know if i feel like tracking down > the patch that fixed it from 4.1.1 ... As 4.1.2 has gone stable, this bug is closed
