atlas @3.10.1_2+gcc47 Error while building libsatlas.dylib on PPC

[jdgleeson]

There are missing symbol errors that cause libtool to fail while creating libsatlas.dylib.

The atlas install/upgrade appears to succeed in spite of these errors.

I think this problem also occurred with Rev 1 of the Portfile, but I didn't suspect a problem with atlas until I upgraded to Rev. 2 and didn't see libtatlas.a

I believe I had the same problem with Rev. 1 because the qrupdate build failed with missing symbols errors (.e.g., _caxpy_) (I had created a soft link for the missing libtatlas.a that qrupdate expects, and nm showed the symbols were not in libatlas.a)

[jdgleeson]

compiled with gcc46

[Veence (Vincent)]

This is normal. The Atlas build process first tries to link using libtool, but it does so without including the libgfortran library, so the link fails miserably and outputs tons of errors related to missing symbols found only in libgfortran; but then the link is redone using gfortran instead of libtool, which pulls the libgfortran library automatically in, and this time the linking phase succeeds. You get a libsatlas all right and you get also a libtatlas which is a link to libsatlas, but with that trick qrupdate should build fine.

[jdgleeson]

I didn't get libtatlas with either gcc46 or gcc47:

$ ls -l /opt46/local/lib/*atlas*
-rw-r--r--  1 root  admin  6885220 Feb 26 18:33 /opt46/local/lib/libatlas.a
-rwxr-xr-x  1 root  admin  9891180 Feb 26 18:33 /opt46/local/lib/libsatlas.dylib
$ ls -l /opt47/local/lib/*atlas*
-rw-r--r--  1 root  admin  6937148 Feb 26 15:57 /opt47/local/lib/libatlas.a
-rwxr-xr-x  1 root  admin  9528628 Feb 26 15:57 /opt47/local/lib/libsatlas.dylib

I expect a library:

$ sysctl hw.logicalcpu
hw.logicalcpu: 2

The missing libtatlas is what caused me to poke around in the log files. It was easy to miss in my description because I emphasized the non-problem as the problem.

[jdgleeson]

I manually created soft links for libtatlas.a, and everything is now linking fine. But if you (Vince) can solve the mystery of why a real libtatlas library does not build, that would be great! Clearly you are right that the the errors I reported are normal. I wish I had tried the soft link before I created the ticket -- then I would have described the right problem.

[jdgleeson]

In case it somehow helps, here are the libraries I see in work/destroot/opt/local/lib

libatlas.a      libcblas.a      libf77blas.a    liblapack.a     libsatlas.dylib

[Veence (Vincent)]

By chance, are you building a universal (ppc/ppc64) atlas?

[Veence (Vincent)]

Nevermind. The problem is caused by libptlapack.a not being built. It is a bug in Atlas, that has to be fixed in a yet to come release: ​http://sourceforge.net/p/math-atlas/bugs/215/ Meanwhile, as a workaround, you did well to soft link manually libsatlas into libtatlas. The problem is that on a bi-processor, you give up some performance.

[jdgleeson]

Thanks for your help, Vince. I'm good with the manual soft link until a better option is available. I haven't tried a universal build yet, but it's on my list of things to do.

[Veence (Vincent)]

Please don’t until I have committed rev. 3 which will clean up some syntactical mistakes and make gcc47 the default compiler. There is still a -t 0 option (no threading) for ppc/pcc64 universal builds encoded in the Portfile, so you are guaranteed to have the wrong libraries at the end. I’ll update today. Thanks for your patience

[larryv (Lawrence Velázquez)]

Replying to vince@…:

Please don’t until I have committed rev. 3 which will clean up some syntactical mistakes and make gcc47 the default compiler.

As per comment:7:ticket:38232, it would be best if I made the [+]gcc47 change when I close that ticket. It should just be a couple of days.

[Veence (Vincent)]

Ok, I will modify the Portfile but keep the changes private until you give the green light.

[jdgleeson]

Replying to vince@…:

Please don’t until I have committed rev. 3 ...

No problem. It will be many weeks before I can start experimenting with universal builds.

[larryv (Lawrence Velázquez)]

Replying to vince@…:

Ok, I will modify the Portfile but keep the changes private until you give the green light.

Ugh, I have to wait on a few people before I can close up #38232. So feel free to commit your changes whenever you like, but leave the default variant at +gcc45; I’ll handle that when everything’s ready. Changing the default variant doesn’t require a revbump anyway.

[Veence (Vincent)]

Thanks Larry, but I can’t, because I have, at the same time, removed the +gcc45 variant. Use of gcc 4.5 breaks ppc builds and produces a much less efficient code than gcc46/47. So I think it’s time for everyone to upgrade. Good luck and thanks so much for your endeavor.

[larryv (Lawrence Velázquez)]

Replying to vince@…:

Thanks Larry, but I can’t, because I have, at the same time, removed the +gcc45 variant. Use of gcc 4.5 breaks ppc builds and produces a much less efficient code than gcc46/47.

Ah, that changes things. I’ll have to sleep on it.

So I think it’s time for everyone to upgrade.

Preaching to the choir :)

[Veence (Vincent)]

Don’t make any nightmare, though! :) As for preaching, during the Pope vacancy, it’s a devious idea :) :)

[cooljeanius (Eric Gallager)]

Cc Me!

[larryv (Lawrence Velázquez)]

Okay Vincent, the default variant is now +gcc47 (r104220). Have at it.

[Veence (Vincent)]

Committed in r104549. Now, let’s pray everything will go smoothly ;)