/bin/sh ../../../libtool --tag=CC --mode=link x86_64-pc-linux-gnu-gcc -prefer-pic -march=native -O2 -pipe -pipe -Wall -fno-common -version-info 1:0:0 -rpath /usr/games/lib64/quakeforge -module -avoid-version -Wl,-O1 -Wl,--enable-new-dtags -Wl,--sort-common -Wl,--as-needed -o cd_file.la cd_file.o -lm *** Warning: Linking the shared library cd_file.la against the non-libtool *** objects cd_file.o is not portable! libtool: link: x86_64-pc-linux-gnu-gcc -shared cd_file.o -Wl,--as-needed -lm -march=native -Wl,-O1 -Wl,--enable-new-dtags -Wl,--sort-common -Wl,-soname -Wl,cd_file.so -o .libs/cd_file.so /usr/lib/gcc/x86_64-pc-linux-gnu/4.4.2/../../../../x86_64-pc-linux-gnu/bin/ld: cd_file.o: relocation R_X86_64_32 against `.data' can not be used when making a shared object; recompile with -fPIC cd_file.o: could not read symbols: Bad value collect2: ld returned 1 exit status
Created attachment 211048 [details] info =emerge --info
This looks like a re-emergence (no pun intended) of bug #165523, which similarly caused a failed build because the Makefile was trying to compile without -fPIC. It seems like there are a lot of places in the Quakeforge code that are like this, since it was originally written for x86 only. The earlier bug #165523 was fixed by using a patch that FreeBSD's packages are using to fix the same bug in Quakeforge. Could something like that be done again here with cd_file.so? I've only recently started using Gentoo heavily, so I don't know where in the ebuild structure such patching would go, to try this myself. It makes me wonder how many -fPIC's need to be put in there to fix it all.
This doesn't seem to be an issue anymore with quakeforge-0.5.5-r2.
