Bugzilla Bug 151832

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 an attachment (id=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