crtbeginT.o needs to be recompiled with -fPIC

[Stu Black]

Binary package hint: gcc-4.4

I'm trying to compile a very simple C library to examine how JNI functions. The code in question comes from http://java.sun.com/developer/onlineTraining/Programming/JDCBook/jniexamp.html . I will attach the file nativelib.c, taken from that site.

When running the command:

gcc -o libnativelib.so -shared -Wl,-soname,libnative.so -I/usr/lib/jvm/java-6-openjdk/include -I/usr/lib/jvm/java-6-openjdk/include/linux nativelib.c -static -lc

gcc says:

/usr/bin/ld: /usr/lib/gcc/x86_64-linux-gnu/4.4.3/crtbeginT.o: relocation R_X86_64_32 against `__DTOR_END__' can not be used when making a shared object; recompile with -fPIC
/usr/lib/gcc/x86_64-linux-gnu/4.4.3/crtbeginT.o: could not read symbols: Bad value
collect2: ld returned 1 exit status

It looks like crtbeginT.o needs to be recompiled with -fPIC.

ProblemType: Bug
DistroRelease: Ubuntu 10.04
Package: gcc-4.4-base 4.4.3-4ubuntu5
ProcVersionSignature: Ubuntu 2.6.32-24.41-server 2.6.32.15+drm33.5
Uname: Linux 2.6.32-24-server x86_64
Architecture: amd64
Date: Thu Sep 16 12:27:58 2010
Dependencies:

InstallationMedia: Ubuntu-Server 10.04 LTS "Lucid Lynx" - Release amd64 (20100427)
ProcEnviron:
 PATH=(custom, user)
 LANG=en_US.utf8
 SHELL=/bin/bash
SourcePackage: gcc-4.4

[Stu Black (dsblack)]

Attaching nativelib.c.

[Anonymous (yanonymous)]

I can confirm this bug when compiling coreutils-8.5 on a fresh lucid 10.04.1 amd64.

$ gcc --version
gcc (Ubuntu 4.4.3-4ubuntu5) 4.4.3
Copyright (C) 2009 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

./configure --prefix=/home/someusername/lfs LDFLAGS="-static"
...
make
...
  CC libstdbuf_so-libstdbuf.o
  CCLD libstdbuf.so
/usr/bin/ld: /usr/lib/gcc/x86_64-linux-gnu/4.4.3/crtbeginT.o: relocation R_X86_64_32 against `__DTOR_END__' can not be used when making a shared object; recompile with -fPIC
/usr/lib/gcc/x86_64-linux-gnu/4.4.3/crtbeginT.o: could not read symbols: Bad value
collect2: ld returned 1 exit status
make[3]: *** [libstdbuf.so] Error 1
...

[Lukas Z. (lukas-zaruba)]

Hi,
I am getting the same error while trying to compile JNI lib. I compiled very similar library before on Ubuntu 9.04 32bit without any problems.

gcc -o libparportaccessor.so -shared -Wl,-soname,libparportaccessor.so
-I/home/lukas/jdk1.6.0_22/include
-I/home/lukas/jdk1.6.0_22/include/linux
net_zarubsys_parporttester_io_ParallelPortAccessor_linux.c -static -lc

/usr/bin/ld: /usr/lib/gcc/x86_64-linux-gnu/4.4.5/crtbeginT.o: relocation R_X86_64_32 against `__DTOR_END__' can not be used when making a shared object; recompile with -fPIC
/usr/lib/gcc/x86_64-linux-gnu/4.4.5/crtbeginT.o: could not read symbols: Bad value
collect2: ld returned 1 exit status

Ubuntu 10.10 amd64 (Lenovo W510 - core i7)

gcc -v output:
Using built-in specs.
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu/Linaro 4.4.4-14ubuntu5' --with-bugurl=file:///usr/share/doc/gcc-4.4/README.Bugs --enable-languages=c,c++,fortran,objc,obj-c++ --prefix=/usr --program-suffix=-4.4 --enable-shared --enable-multiarch --enable-linker-build-id --with-system-zlib --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --with-gxx-include-dir=/usr/include/c++/4.4 --libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug --enable-objc-gc --disable-werror --with-arch-32=i686 --with-tune=generic --enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu
Thread model: posix
gcc version 4.4.5 (Ubuntu/Linaro 4.4.4-14ubuntu5)

Thanks for any solution.

Best

Lukas Zaruba

[Erel Segal (erelsgl)]

Same error here, with the same JNI package. Any workaround?

[Erel Segal (erelsgl)]

NOTE: See here: https://bugzilla.redhat.com/show_bug.cgi?id=214465
"crtbeginT.o is not, and should not be PIC. `gcc -shared` should link to crtbeginS.o"

[Erel Segal (erelsgl)]

OK, I found a workaround:

$ cd /usr/lib/gcc/x86_64-linux-gnu/4.4
$ sudo cp crtbeginT.o crtbeginT.orig.o
$ sudo cp crtbeginS.o crtbeginT.o

Also, add -fPIC to the gcc command above:

gcc -o libnativelib.so -shared -Wl,-soname,libnative.so -I/usr/lib/jvm/java-6-openjdk/include -I/usr/lib/jvm/java-6-openjdk/include/linux nativelib.c -static -lc -fPIC

And walla, you have a fresh so library!

[Launchpad Janitor (janitor)]

Status changed to 'Confirmed' because the bug affects multiple users.

[Stanislav (stanislav-r2)]

I was compiling one custom library today and found that exactly this bug still exist in:
gcc (Ubuntu/Linaro 4.6.3-1ubuntu5) 4.6.3
OS: Ubuntu 12.04.5 LTS x86_64
Codename: precise

Is somebody going to fix it 5 years after discovery?

[ksclarke (ksclarke)]

Also an issue with gcc-5

gcc (Ubuntu 5.2.1-22ubuntu2) 5.2.1 20151010
OS: Ubuntu 15.10 x86_64
Codename: wily

The above workaround (copying crtbeginS.o) still works though.

[Matthias Klose (doko)]

there's nothing wrong from my point of view. you can't link static libs when building shared libraries.

[Doug Royer (douglasroyer)]

You CAN link ARCHIVE libraries when building dynamic libraries.
As long as the archive (.a) was compiled with -fPIC/-fpic.

I do it all the time when building shared libraries for embedded devices, where you do not want to distribute a massive shared library, or multiple shared libraries. By building the embedded archive libraries with -fPIC/-fpic, you can link them and build one new shared library. In fact many open source project build multiple archive libs, then link at the final step into the final dynamic library.

The problem is not -shared which is misleading. The issue is was the archive library built with -fPIC/-fpic or not?

The bug exists, because when building a -fPIC/fpic archive library (linked with -Bstatic libName -Bdynamc, where libName WAS compiled dynamic, you get the error.