#1 build problems on em64t

Bill Barth

On a (basically) CentOS 4.1 EM64T (i.e. 64-bit Inteal
x86) system, I'm running across the following class of
errors when building PerfSuite:

gcc -DHAVE_CONFIG_H -I. -I. -I../.. -g -O2 -MT
libperfsuite_la-utils.lo -MD -MP -MF
.deps/libperfsuite_la-utils.Tpo -c utils.c -o
/bin/sh ../../libtool --tag=CC --mode=link gcc -g -O2
-o libperfsuite.la -rpath /usr/local/lib
-version-info 1:0:0 libperfsuite_la-cpuid.lo
libperfsuite_la-debug.lo libperfsuite_la-environment.lo
libperfsuite_la-error.lo libperfsuite_la-futils.lo
libperfsuite_la-hash.lo libperfsuite_la-malloc.lo
libperfsuite_la-procfs.lo libperfsuite_la-process.lo
libperfsuite_la-timers.lo libperfsuite_la-utils.lo
gcc -shared .libs/libperfsuite_la-cpuid.o
.libs/libperfsuite_la-utils.o -Wl,-soname
-Wl,libperfsuite.so.1 -o
.libs/libperfsuite_la-cpuid.o: relocation R_X86_64_32S
against `a local symbol' can not be used when making a
shared object; recompile with -fPIC
.libs/libperfsuite_la-cpuid.o: could not read symbols:
Bad value

This was generated from make after the following
configure line:

./configure --with-papi=$PAPI_DIR --disable-static

I can generate similar errors (i.e. same basic error
message but occurring in a different place) by dropping
the --disable-static and --without-pic from my
configure line.

Some limited googling hasn't been particularly helpful.
Any thoughts?



  • Rick Kufrin

    Rick Kufrin - 2006-07-15

    Logged In: YES

    Bill - does this happen if you use invoke configure with
    CFLAGS="-m64 -g" and do not alter the default settings for
    PIC or -enable/-disable-static? The error message is
    similar to what can occur on a standard x86 machine when
    compiling the assembly code necessary to use the CPUID


    p.s. the PerfSuite project typically hasn't used SourceForge
    "tracker" for bug/problem reports, instead there is a
    perfsuite-bugs mailing list. Apologies for the delay in reply.

  • Rick Kufrin

    Rick Kufrin - 2006-07-15
    • assigned_to: nobody --> rkufrin
  • Bill Barth

    Bill Barth - 2006-07-19

    Logged In: YES

    Sorry for the delay in response. I tried your suggestion,
    and I get an error in the same vein:

    /bin/sh ../../../../libtool --tag=CC --mode=link gcc -m64
    -g -o libpsbfd.la -rpath /usr/local/lib/psbfd0.2 -lbfd
    -liberty -version-info 1:0:0 libpsbfd_la-Bfd_control.lo
    libpsbfd_la-Bfd_init.lo libpsbfd_la-Bfd_inquire.lo
    gcc -shared .libs/libpsbfd_la-Bfd_control.o
    .libs/libpsbfd_la-Bfd_init.o .libs/libpsbfd_la-Bfd_inquire.o
    .libs/libpsbfd_la-Bfd_lookup.o -lbfd -liberty -m64
    -Wl,-soname -Wl,libpsbfd.so.1 -o .libs/libpsbfd.so.1.0.0
    relocation R_X86_64_32 against `a local symbol' can not be
    used when making a shared object; recompile with -fPIC
    could not read symbols: Bad value
    collect2: ld returned 1 exit status

    (This is actually the same error that I get with a naked
    './configure; make'.) Anything else I should try?


  • Rick Kufrin

    Rick Kufrin - 2006-07-19

    Logged In: YES

    Bill - thanks for the update. I might have missed this in
    your earlier message, but the make output you provided seems
    to me to have another clue. It's possible that the BFD
    library (libbfd) could be the issue. I have seen something
    similar on other machines.

    Specifically, I wonder if a shared library version of libbfd
    is not available on your system, at least with "standard"
    naming conventions. As you know, usually for a library
    libXXX, there will be a static version libXXX.a, a shared
    version libXXX-N.N.N.so (with the N.N.N being shared library
    versioning info), and then libXXX.so which is a symbolic
    link to the latest "real" library - in this case

    What I have seen are systems where the .a version exists as
    well as the .so with versioning numbers, but the vanilla
    libXXX.so is missing. In this case, the PerfSuite build
    tries to link against the only libXXX it can find (libbfd.a)
    and it fails with the PIC vs. non-PIC error.

    There are two things to try: first is to see if there is a
    libbfd.so on your machine, which should be a symlink to the
    actual current .so. If there isn't, and you have admin
    privs, you could try creating the symlink yourself and
    retrying the build. If that is not possible, then there is
    a configure option that PerfSuite supports:
    --disable-binutils. This should defeat attempting to use
    anything from BFD and may solve the problem as well.

    Hope this helps, let me know how it goes.


  • Rick Kufrin

    Rick Kufrin - 2006-08-12
    • status: open --> closed
  • Rick Kufrin

    Rick Kufrin - 2006-08-12

    Logged In: YES

    Closed due to lack of further information/response.


Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:

No, thanks