Atlas 3.10.0_1 - build failure

[mdbecque@…]

Building atlas on a G5 running 10.5.8. No error message but I've attached the main log below because the build quit <see below>.

[mdbecque@…]

Atlas build log file

[mf2k (Frank Schima)]

This is not a clean build log. Please clean atlas, re-try the install, and then post the new main.log if it fails again.

[mdbecque@…]

Replying to macsforever2000@…:

This is not a clean build log. Please clean atlas, re-try the install, and then post the new main.log if it fails again.

I did a clean build and had an odd end. I uploaded the build log.

[Veence (Vincent)]

Thanks for the new log. There are two sort of errors. The first has to do with the ATL_* routines and was theoretically fixed long ago; I wonder why it shows up again. The second one is yet unregistered, I'll have to investigate a bit further by compiling on my old G5 MacPro to see if I can reproduce this. I'll keep you posted.

[dershow]

Cc Me!

[jdgleeson]

Cc Me!

[Veence (Vincent)]

Should be fixed (at last) in r100521. The issue was more involved than it appeared at first sight, wherefore the delay. Sorry for keeping you waiting.

[desmith@…]

/opt/local/var/macports/logs/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_math_atlas/atlas/main.log

[desmith@…]

Attempting to build on PowerBook G4 1.33 GHz, OS 10.5.8, XCode 3.1.4 (the latest that will install on this system). My previous build log showed the same sequence of errors as those in the log posted by mdbecque, so I waited for this fix. Attempted a clean install, sudo port clean --all -f atlas, sudo port install atlas

Current logfile attached above.

Many thanks.

[Veence (Vincent)]

Does this still happen with the new release (3.10.1)?

[jdgleeson]

atlas 3.10.1 builds for me using gcc46 and gcc47 on OS X 10.5.8 PPC.

I get Internal Compiler Errors with gcc45. I'm satisfied with the workaround of using newer versions of gcc, but I'll create a ticket if someone would like me to.

[Veence (Vincent)]

Thank for trying this out. I’m afraid we can’t do much about the gcc45 internal errors: these are far too intricate to solve, and I’m not sure gcc45 is maintained anymore. I think with the release of gcc48 it’ll be time to move the default compiler from gcc45 to gcc46 or newer. Thanks again.

[desmith@…]

jdgleeson and Vincent, thank you both

I assume I am seeing the same thing, but don't know enough to be sure. The error stream simply reports ---> Configuring atlas ---> Building atlas Error: org.macports.build for port atlas returned: command execution ---> failed To report a bug, follow the instructions in the guide:

​http://guide.macports.org/#project.tickets

Error: Processing of port atlas failed

and this isn't showing up in the atlas logfile like the errors in previous builds did.

May I ask how I set the default compiler to other than gcc45, so I can reproduce your successful build? If this is too ignorant a question for the ticket, an offline email would be appreciated. Thanks.

[Veence (Vincent)]

Please build atlas with the +gcc46 or +gcc47 option. But it is peculiar that you get nothing in the log file. Are you sure it really contains no telltale whatsoever?

[jdgleeson]

Replying to desmith@…:

May I ask how I set the default compiler to other than gcc45, so I can reproduce your successful build? If this is too ignorant a question for the ticket, an offline email would be appreciated. Thanks.

Open /opt/local/etc/macports/variants.conf in your favorite editor (You may want to use sudo, since you need admin privileges to save the changes) and add the line +gcc46 for example. Any port that has a gcc46 variant will use it, and any that doesn't will ignore it.

[desmith@…]

Thank you both. Atlas does build now. There may still be a problem due to the earlier disabling of threaded libraries on atlas, which shows up as a build failure for a subsequent build of qrupdate. This was originally listed in ticket 35594 but then moved to ticket 35683 as being an atlas problem and not a qrupdate problem (?). A Portfile.diff was posted on that ticket by Zan which if I understand produced something that qrupdate would accept as a threaded library, but -ltatlas still shows missing in this build (logfile attached above). Is this a problem with the port or a patch I should be applying manually? Thanks.

[Veence (Vincent)]

Building threaded library on mono-processors (G4, G5 machines, mainly) not only produce inferior results (according to Clint, Atlas maintainer), but also causes assertion errors because OpenMP fails to create the number of threads Atlas requires. Currently, threading is disabled on PPC machines; Ideally, I should re-enable it by testing some sysctl against the number of processors/cores rather that blindly disabling it according to the arch.

[Veence (Vincent)]

As for qrupdate, the Portfile should link against tatlas, which is more efficient on multi-core/multi-processor machines, but fallback to satlas in case tatlas does not exist, which is the case on PPC machines. What I can do is modify the portfile to automatically create a libtatlas.dylib on PPC machines that would be a link to libsatlas.dylib. This way, dependent ports would build on any system.

[Veence (Vincent)]

I have updated the Portfile in r103464 to automatically detect the number of processors present on the system and build threaded or non-threaded. If there is only one processor (e.g.: PPC G4), the sequential library is built, and then a symlink is made so that libtatlas == libsatlas. Dependencies should build fine with that trick.

[desmith@…]

Thank you Vincent.

Looks all good. The ports tree finds the revision, atlas still builds, and downstream dependents at least as far as qrupdate and octave build and link successfully. I think that takes care of my difficulties. Many thanks.

[Veence (Vincent)]

Glad to hear this.

I thus close the bug as 'fixed'. Thanks for your time and patience.