Compiling CVS HEAD

[Keith Seitz]

On 08/19/2009 08:13 AM, Russel Winder wrote:
> and then run make.  If I then run make again I see:
>
>          make[7]: Entering directory `/home/Checkouts/CVS/Insight/sid/component/cgen-cpu'
>          /bin/bash ./libtool --tag=CXX --mode=link g++ -g -O2     -o libcgencpu.la -rpath /opt/insight-cvs/lib/sidcomp -module -no-undefined compCGEN.lo cgen-fpu.lo fp.lo tracedis.lo arm7t/libarm7t.la  -L../../../libiberty/pic -L../../../libiberty -liberty cgen-asm.lo cgen-dis.lo cgen-opc.lo dis-buf.lo dis-init.lo cgen-bitset.lo -lpthread -lm
>          g++ -shared -nostdlib /usr/lib/gcc/x86_64-linux-gnu/4.3.3/../../../../lib/crti.o /usr/lib/gcc/x86_64-linux-gnu/4.3.3/crtbeginS.o  .libs/compCGEN.o .libs/cgen-fpu.o .libs/fp.o .libs/tracedis.o .libs/cgen-asm.o .libs/cgen-dis.o .libs/cgen-opc.o .libs/dis-buf.o .libs/dis-init.o .libs/cgen-bitset.o -Wl,--whole-archive arm7t/.libs/libarm7t.a -Wl,--no-whole-archive  -L/home/Checkouts/CVS/Insight/libiberty/pic -L/home/Checkouts/CVS/Insight/libiberty -liberty -lpthread -L/usr/lib/gcc/x86_64-linux-gnu/4.3.3 -L/usr/lib/gcc/x86_64-linux-gnu/4.3.3/../../../../lib -L/lib/../lib -L/usr/lib/../lib -L/usr/lib/gcc/x86_64-linux-gnu/4.3.3/../../.. -lstdc++ -lm -lc -lgcc_s /usr/lib/gcc/x86_64-linux-gnu/4.3.3/crtendS.o /usr/lib/gcc/x86_64-linux-gnu/4.3.3/../../../../lib/crtn.o  -Wl,-soname -Wl,libcgencpu.so.0 -o .libs/libcgencpu.so.0.0.0
>          /usr/bin/ld: /home/Checkouts/CVS/Insight/libiberty/libiberty.a(xmalloc.o): relocation R_X86_64_32 against `a local symbol' can not be used when making a shared object; recompile with -fPIC
>          /home/Checkouts/CVS/Insight/libiberty/libiberty.a: could not read symbols: Bad value
>          collect2: ld returned 1 exit status
>
> and
>
>          make[5]: Entering directory `/home/Checkouts/CVS/Insight/sid/component/loader'
>          /bin/bash ../libtool --tag=CXX --mode=link g++  -g -O2   -o libloader.la -rpath /opt/insight-cvs/lib/sidcomp -module -no-undefined compLoader.lo elfload.lo -L../../../libiberty/pic -L../../../libiberty -liberty -lstdc++ -lm
>          g++ -shared -nostdlib /usr/lib/gcc/x86_64-linux-gnu/4.3.3/../../../../lib/crti.o /usr/lib/gcc/x86_64-linux-gnu/4.3.3/crtbeginS.o  .libs/compLoader.o .libs/elfload.o  -L/home/Checkouts/CVS/Insight/libiberty/pic -L/home/Checkouts/CVS/Insight/libiberty -liberty -L/usr/lib/gcc/x86_64-linux-gnu/4.3.3 -L/usr/lib/gcc/x86_64-linux-gnu/4.3.3/../../../../lib -L/lib/../lib -L/usr/lib/../lib -L/usr/lib/gcc/x86_64-linux-gnu/4.3.3/../../.. -lstdc++ -lm -lc -lgcc_s /usr/lib/gcc/x86_64-linux-gnu/4.3.3/crtendS.o /usr/lib/gcc/x86_64-linux-gnu/4.3.3/../../../../lib/crtn.o  -Wl,-soname -Wl,libloader.so.0 -o .libs/libloader.so.0.0.0
>          /usr/bin/ld: /home/Checkouts/CVS/Insight/libiberty/libiberty.a(xmalloc.o): relocation R_X86_64_32 against `a local symbol' can not be used when making a shared object; recompile with -fPIC
>          /home/Checkouts/CVS/Insight/libiberty/libiberty.a: could not read symbols: Bad value
>          collect2: ld returned 1 exit status

Try updating your sources and see if this was fixed at all. There was a 
big autotools update a week or two ago. If your problem persists, you 
should contact the libiberty maintainers. From src/MAINTAINERS:

intl/; config.rhost; libiberty/; libiberty's part of include/
         gcc: http://gcc.gnu.org
         Changes need to be done in tandem with the official GCC
         sources or submitted to the master file maintainer and brought
         in via a merge.  Note: approved patches in gcc's libiberty or
         intl are automatically approved in this libiberty and intl also;
         feel free to merge them yourself if needed sooner than the next
         merge.  Otherwise, changes are automatically merged, usually
         within a day.

Keith