Relocation without solution towards symbol free@@GLIBC_2.2.5

[teto]

I upgraded to ubuntu xenial and I have:

[283/367] cxxprogram: build/test/test-nanosleep.cc.16.o -> build/bin_dce/test-nanosleep
[284/367] cxxprogram: build/test/test-malloc.cc.22.o -> build/bin_dce/test-malloc
[285/367] cxxprogram: build/test/test-local-socket.cc.37.o -> build/bin_dce/test-local-socket
[286/367] cxxprogram: build/test/test-pthread-key.cc.20.o -> build/bin_dce/test-pthread-key
/usr/bin/ld.bfd.real: test/test-tsearch.cc.50.o(.text+0x2c5): réadressage R_X86_64_PLTOFF64 sans solution vers le symbole « free@@GLIBC_2.2.5 »
/usr/bin/ld.bfd.real : échec de l'édition de liens finale : Section non-représentable pour la sortie
collect2: error: ld returned 1 exit status
Waf: Leaving directory `/home/teto/dce/build'
Build failed

I don't really know how to fix this.

gcc -v:

Using built-in specs.
COLLECT_GCC=/usr/bin/gcc-5.real
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/5/lto-wrapper
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu 5.3.1-14ubuntu2' --with-bugurl=file:///usr/share/doc/gcc-5/README.Bugs --enable-languages=c,ada,c++,java,go,d,fortran,objc,obj-c++ --prefix=/usr --program-suffix=-5 --enable-shared --enable-linker-build-id --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --with-default-libstdcxx-abi=new --enable-gnu-unique-object --disable-vtable-verify --enable-libmpx --enable-plugin --with-system-zlib --disable-browser-plugin --enable-java-awt=gtk --enable-gtk-cairo --with-java-home=/usr/lib/jvm/java-1.5.0-gcj-5-amd64/jre --enable-java-home --with-jvm-root-dir=/usr/lib/jvm/java-1.5.0-gcj-5-amd64 --with-jvm-jar-dir=/usr/lib/jvm-exports/java-1.5.0-gcj-5-amd64 --with-arch-directory=amd64 --with-ecj-jar=/usr/share/java/eclipse-ecj.jar --enable-objc-gc --enable-multiarch --disable-werror --with-arch-32=i686 --with-abi=m64 --with-multilib-list=m32,m64,mx32 --enable-multilib --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 5.3.1 20160413 (Ubuntu 5.3.1-14ubuntu2) 

[teto]

asked for some help at http://stackoverflow.com/questions/37847353/relocation-error-in-dce-r-x86-64-pltoff64

[teto]

with gcc 6 (default for ubuntu 16.10), I have the same problem x100 and sitll no idea to solve it. Strangely enough, the clang branch compiles fine :/

[teto]

I received an anonymous tip, which really helps:

My take on this situation is that the Ubuntu 16.10 release notes
should have detailed everything I've found out and will list in this
email, and that the bfd linker just doesn't work with large mode PIE
programs.  I did verify that the clang issue is known but likely never
to be fixed upstream and that gcc just turned off ODR reporting by
default to deal with the same problem.  None of these issues existed
for me in Ubuntu 16.04.1 LTS which 'just worked', but it doesn't look
like gcc-6.2.0 will ever be packaged for 16.04.1, so I began this
adventure.

Now for some details....

I suspect the Ubuntu faithful will say it's not a bug in the tools,
it's a bug in how I was using the tools.   In summary, when using
gcc-6.2.0 on Ubuntu 16.10, if you want a large model 'normal'
executable, you compile with these additional options:

-fno-pie -fno-pic -fno-PIC -mcmodel=large

and link with this additional option:

-no-pie

If you want the new style PIE code (which they cleary expect us to
use), you compile with different options:

-fPIC -mcmodel=large

and link with different options:

-pie -fPIC -fuse-ld=gold

because the bfd linker just won't work right any more when generating
a large code model C program in PIE style.  I think that is a genuine
bug, but I'm not eager to argue about it since the knee-jerk response
whenever a linker issue comes up is that everybody says 'use gold' and
in this case that works.  Maybe some of those options aren't strictly
required - I went for the first working set I could find and didn't
try to find the miniumum set of options required.

After I sent the previous email to you, I learned that the clang-3.9.0
on that version of Ubuntu has problems too if you turn on the
sanitizers and have two identical string literals (I had "true" and
"false" in two different files) and use large mode and use link time
optimization.  It says I violated the one definition rule.  My
research shows that ODR is a C++ thing, not a C thing (my code is C).
I had to add 'detect_odr_violation=0' to my ASAN_OPTIONS for clang.

I encourage you not to just blindly take my word for these things, but
instead to test all of this yourself with your code to see if it works
for you.  If it does, you could report things upstream using your
examples.  I lost a whole day figuring this stuff out, and I lack the
energy or the enthusiasm to jump through the many hoops it would take
to report the bug upstream since I'm pretty sure they will respond
with something equivalent to this:

1.  PIE is good for you - it's safer

2.  Nobody needs large model - just don't use it - it's slower than
rip-relative code anyway

3.  Use the gold linker - it's faster, and the bfd linker is no longer
seriously maintained for ELF

In my Makefile (I use GNU make) I have code for adding CFLAGS.  You
can force PIE or not with something like "make whatever PIE=1" or
"make whatever PIE=0" or if you don't specify the "PIE=" part then it
does PIE in the case where the compiler was built with the
--enable-default-pie flag.  I use gmail, so the lines here may wrap
badly, but you'll see the idea anyway I think:

PIE?=$(shell if gcc -v 2>&1 | grep -q -- '--enable-default-pie'; then
echo 1; else echo 0; fi)
ifeq ($(PIE),0)
    # We want a traditional executable
    CFLAGS+=-fno-pie -fno-pic -fno-PIC
else
    # We want a PIE executable
    CFLAGS+=-fPIC
endif

And I have this for adding settings to LDFLAGS:

ifeq ($(PIE),0)
    # We want a traditional executable
    LDFLAGS+=-no-pie
else
    # We want a PIE executable
    LDFLAGS+=-pie -fPIC -fuse-ld=gold
endif

I confirm using the previously recommanded CFLAGS and LDFLAGS solved the g++6 problems on the clang branch (the master fails to compile because of other valid concerns).

[thehajime]

I will fix by using gold linker.

[thehajime]

I was planning to switch to gold linker but using gold linker introduces other test failure so, I postpone this fix.