Learn how easy it is to sync an existing GitHub or Google Code repo to a SourceForge project! See Demo

Close

#157 libatlas.a compiled as static v 3.9.24 and v 3.9.25 only

Developer
closed-fixed
5
2012-04-04
2010-09-02
Casey Bartlett
No

Here is my configure line:

../configure -b 64 -Fa alg -fPIC -Ss flapack /home/me/lapack/lapack_LINUX.a

No errors during compile/install, however when trying to make shared in lib:

make shared
rm -f libatlas.so liblapack.so
make libatlas.so libf77blas.so libcblas.so liblapack.so
make[1]: Entering directory `/home/casey/AT25/ATLAS/Obj/lib'
ld -melf_x86_64 -shared -soname /usr/local/atlas/lib/libatlas.so -o libatlas.so \ -rpath-link /usr/local/atlas/lib \ --whole-archive libatlas.a --no-whole-archive -lc -lpthread -lm
ld: libatlas.a(ATL_dger2k__2.o): relocation R_X86_64_32 against `a local symbol' can not be used when making a shared object; recompile with -fPIC
libatlas.a(ATL_dger2k__2.o): could not read symbols: Bad value
make[1]: *** [libatlas.so] Error 1
make[1]: Leaving directory `/home/casey/AT25/ATLAS/Obj/lib'
make: *** [shared] Error 2

Some more info:

uname -a
Linux 2.6.18-194.11.3.el5 #1 SMP Mon Aug 30 16:19:16 EDT 2010 x86_64 x86_64 x86_64 GNU/Linux

cat /etc/redhat-release
CentOS release 5.5 (Final)

I pulled version 3.9.23 and was able to build shared libraries with no problems. It appears somewhere in the make process -fPIC was not passed (the Makefiles are too big for me to sort through).

Discussion

  • OK, if I am *very* lucky, this may be fixed in 3.9.26. Can you give it a try, and let me know if this still occurs. If so, I need to put it on my very long "fix this L2 tuning framework error" queue.

    Thanks,
    Clint

     
    • milestone: --> 148063
    • labels: --> 360151
     
    • assigned_to: nobody --> rwhaley
     
  • At least on my machine, I got an error similar to the above when calling a routine that *was* built with -fPIC. I finally had to rewrite some kernel code to avoid making the function call in question, because I couldn't figure out why gcc was coughing up blood on this.

    Can you try installing 3.9.28, and see if the rewrites I did have automagically fixed this for you? If not, it's possible I need to kludge ger2k as well.

    Thanks,
    Clint

     
  • Casey Bartlett
    Casey Bartlett
    2010-10-26

    Hey I'll be working on it tomorrow, I'll let you know if those bugs are fixed. Appreciate the response.

     
  • Casey Bartlett
    Casey Bartlett
    2010-10-26

    Unfortunately I get the same (at least is referencing a similar symbol) error (configured using the same flags as before):

    make[1]: Entering directory `~/ATLAS3.9.28/ATLAS/MyObj/lib'
    ld -melf_x86_64 -shared -soname /usr/local/atlas/lib/libatlas.so -o libatlas.so \ -rpath-link /usr/local/atlas/lib \ --whole-archive libatlas.a --no-whole-archive -lc -lpthread -lm
    ld: libatlas.a(ATL_dgerk__900001.o): relocation R_X86_64_32 against `a local symbol' can not be used when making a shared object; recompile with -fPIC
    libatlas.a(ATL_dgerk__900001.o): could not read symbols: Bad value

    This was for ATLAS version 3.9.28. I'll try the v.26 in about 30 minutes (takes forever to compile even on 2 bare metal Xeon 5500's)

     
  • Casey Bartlett
    Casey Bartlett
    2010-10-26

    Try for Version 3.9.26 fails as well:

    make shared
    rm -f libatlas.so liblapack.so
    make libatlas.so libf77blas.so libcblas.so liblapack.so
    make[1]: Entering directory `/home/casey/ATLAS26/ATLAS/MyObj/lib'
    ld -melf_x86_64 -shared -soname /usr/local/atlas/lib/libatlas.so -o libatlas.so \ -rpath-link /usr/local/atlas/lib \ --whole-archive libatlas.a --no-whole-archive -lc -lpthread -lm
    ld: libatlas.a(ATL_dgerk__900001.o): relocation R_X86_64_32 against `a local symbol' can not be used when making a shared object; recompile with -fPIC
    libatlas.a(ATL_dgerk__900001.o): could not read symbols: Bad value

    No luck there.

    In summary both 3.9.26 and 3.9.28 shared object builds fail.

     
  • Casey,

    In your 3.9.28 install, did you throw the --shared argument to configure? If not, can you try that?

    If an install with --shared still produces the same error, please create and post the error file (if the error file is too large to post, just e-mail it to me directly).

    Thanks,
    Clint

     
  • Casey Bartlett
    Casey Bartlett
    2010-10-27

    New error log has been uploaded as requested. I did go back and recompile with the --shared flag. Hope this helps

     
  • The error log is for 3.9.26, which is known to not work. Please try 3.9.28, and post the error file, if any, from that.

    Thanks,
    Clint

     
  • Casey Bartlett
    Casey Bartlett
    2010-10-28

    3.9.28 Error file

     
    Attachments
  • Casey Bartlett
    Casey Bartlett
    2010-10-28

    This should be it - hopefully it is of some use

     
  • I am getting the same error with 3.9.32.

     
  • Dang. I think I know the fix, I just don't know why it causes a problem. I've fixed this before by removing a function call for cleanup in my kernel code. However, the routine it is calling *is* compiled with -fPIC, AFAIK, so I'm really not sure why there is a problem.

    I will try to look at this again, until then I'm escalating this to the outstanding bugs tracker.

    Thanks,
    Clint

     
    • milestone: 148063 -->
    • labels: 360151 -->
     
    • milestone: --> Developer
    • labels: --> Install problem
    • status: open --> open-accepted
     
    • status: open-accepted --> closed-fixed
     
  • Hey, I believe I fixed this a loooong time ago. Please reopen if the problem occurs with a modern developer release.

    Thanks!
    Clint