#855 Error on building unthreaded libraries (-t 0)

[Hannes Schabauer]

Building ATLAS 3.10.0 libraries after configuring with option -t 0 fails when adding to archive (using ar, see snippet below); -t 0 on ATLAS 3.8.4 works fine. The build platform is an Ubuntu 12.04.1 LTS, but the problem seems to occur on other Linux platforms, too.

***
[..]
ar r cblas_dptgemm.o cblas_dptsymm.o cblas_dptsyr2k.o cblas_dptsyrk.o cblas_dpttrmm.o cblas_dpttrsm.o cblas_xerbla.o cblas_errprn.o
ar: cblas_dptgemm.o: File format not recognized
make[4]: *** [dptlvl3.grd] Error 1
make[4]: Leaving directory `/home/mac/tmp/ATLAS/TMP/interfaces/blas/C/src\'
make[3]: *** [dptlvl3] Error 2
make[3]: Leaving directory `/home/mac/tmp/ATLAS/TMP/interfaces/blas/C/src\'
make[2]: *** [IBuildPtlibs0] Error 2
***

[Hannes Schabauer]

ATLAS 3.10.0 unsuccessful build (tail of "make" output)

[Christoph Freysoldt]

Hi Clint,

this is Christoph Freysoldt, current main developer of the SPHInX density-functional theory package. We have been using ATLAS with great joy for many years, and I was very excited when I discovered that the 3.10 is out, and wanted to test it. We presently only need the serial ATLAS, and have been configuring with -t 0 for quite some time. [I know it must be frustrating for you that people still look for the serial ATLAS when you spend so much effort for getting it parallel. Yet, we do our parallelization via MPI, and then need a highly performant single-threaded BLAS.]

Like Hannes, I also observe a problem when using -t 0 with the 3.10.0 on my 12-core Intel Xeon with Fedora 15 Linux and gcc 4.6.1. In my case, however, I do not get any compilation error, but later the linker complains on the shared object built out of libatlas.a: it seems that ATL_SetAtomicCount, ATL_DecAtomicCount and two more are undefined in the (serial) shared object.
I figured out that these should be compiled from src/threads. I understand that one wouldn't compile any thread-related stuff if there are no threads, but it seems that at least a few threaded functions are and end up in libatlas.a. Shouldn't we use -t 0 any more to suppress building the threaded code? It still worked in the 3.9.55, the version we had used until now.

This is not an urgent issue, we can survive by not using -t 0 and ignore the threaded libs (I presume that we don't end up using the threaded code in the serial library). @Hannes: maybe this also solves your problem... I also did not check whether building the threaded part takes any considerable amount of extra-time. Anyway, it would be convenient to either get a pure serial ATLAS with -t 0, or to get a configuration error early on if you no longer support it.

I somehow suspect that Hannes and my problems are related, so I did not open a new ticket.

Best wishes,

Christoph

[R. Clint Whaley]

NOTE: this is an answer to original question, not freyso comment, which I'll read next . . .

OK, but does the above cause in problems? The reason is that I think -t 0 will indeed not build the pthreads lib, but you should still have valid serial libraries built. Is this not the case?

Let me know,
Clint

[R. Clint Whaley]

Christoph,

Can you open up a new ticket for your problem? In particular, what command did you use to get the undefined symbols? ATLAS shoves some stuff that might be partially defined with -t0 in libatlas.a, but none of it should be invoked by the serial libs. So, I'll need to see your link line that is failing, and let's do that in a new report.

Thanks,
Clint

[Hannes Schabauer]

Clint, it looks like all the non-threaded libraries were created correctly on my platform.

Building -t 0 generates:
ls lib/*.a -l
-rw-r--r-- 1 user user 11772766 Oct 10 10:24 lib/libatlas.a
-rw-r--r-- 1 user user 454652 Oct 10 10:23 lib/libcblas.a
-rw-r--r-- 1 user user 574024 Oct 10 10:24 lib/libf77blas.a
-rw-r--r-- 1 user user 615946 Oct 10 10:24 lib/libf77refblas.a
-rw-r--r-- 1 user user 1075516 Oct 10 10:24 lib/liblapack.a
-rw-r--r-- 1 user user 507256 Oct 10 10:16 lib/libtstatlas.a

Building WITHOUT -t 0 on the same platform generates:
ls -la lib/*.a -l
-rw-r--r-- 1 user user 11777460 Oct 10 10:34 lib/libatlas.a
-rw-r--r-- 1 user user 454684 Oct 10 10:32 lib/libcblas.a
-rw-r--r-- 1 user user 574024 Oct 10 10:33 lib/libf77blas.a
-rw-r--r-- 1 user user 615946 Oct 10 10:34 lib/libf77refblas.a
-rw-r--r-- 1 user user 1075516 Oct 10 10:33 lib/liblapack.a
-rw-r--r-- 1 user user 455266 Oct 10 10:34 lib/libptcblas.a
-rw-r--r-- 1 user user 574420 Oct 10 10:34 lib/libptf77blas.a
-rw-r--r-- 1 user user 1240580 Oct 10 10:34 lib/libptlapack.a
-rw-r--r-- 1 user user 507256 Oct 10 10:26 lib/libtstatlas.a

The reason why I wrote the support request is just that when I saw "Error" popping up, I was not aware how relevant that is in this case. We need the single threaded routines, because in phylogenetics we are mostly dealing with problems of order 61 (or even just 4 for nucleotide problems). It looks like the relevant .a files are created and complete when comparing the "-t 0" with the "normal" one.

..and of course I think that ATLAS is an awesome project!

[R. Clint Whaley]

OK, good news that the serial stuff works in this case. I must admit that the install could be a lot cleaner, but when supporting corner cases (no threaded libs, no fortran compiler), I opt for minimal change from original install (to avoid specializations that make maintanence even more difficult), even at the cost of error messages.

I'm closing this for now as works for me. Please reopen it if there are problem swith the serial libraries!

Thanks,
Clint