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

[Casey Bartlett]

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).

[R. Clint Whaley]

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

[R. Clint Whaley]

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]

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

[Casey Bartlett]

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]

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.

[R. Clint Whaley]

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]

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

[R. Clint Whaley]

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]

3.9.28 Error file

[Casey Bartlett]

This should be it - hopefully it is of some use

[Nobody/Anonymous]

I am getting the same error with 3.9.32.

[R. Clint Whaley]

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

[R. Clint Whaley]

Hey, I believe I fixed this a loooong time ago. Please reopen if the problem occurs with a modern developer release.

Thanks!
Clint