atlas: undefined symbols _ATL_DecAtomicCount

[macports@…]

Atlas wont compile... i use the rsync area. Snow leopard, iMac x64.

Please if you need more log files or any file tell me.

End of build log file follows.

:info:build ATLAS install complete.  Examine 
:info:build ATLAS/bin/<arch>/INSTALL_LOG/SUMMARY.LOG for details.
:info:build /usr/bin/make clean
:info:build rm -rf *.dSYM
:info:build rm -rf *.o x* config?.out *core*
:debug:build Executing proc-post-org.macports.build-build-0
:info:build Undefined symbols:
:info:build   "_ATL_DecAtomicCount", referenced from:
:info:build       _ATL_dyntlaunch in libatlas.a(ATL_dyntlaunch.o)
:info:build       _ATL_dyntlaunch in libatlas.a(ATL_dyntlaunch.o)
:info:build ld: symbol(s) not found
:info:build shell command "cd /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_ports_math_atlas/work/atlas-3.9.37/build/lib &&  ( test ! -e libatlas.a ||  /usr/bin/ld -arch x86_64 -dynamic -dylib -single_module -dead_strip  -x -all_load -L. -L/opt/local/lib/gcc44/x86_64  -L/opt/local/lib/gcc44 -ldylib1.o  -dylib_install_name /opt/local/lib/libatlas.dylib  libatlas.a -o libatlas.dylib  -lSystem  )" returned error 1
:error:build Target org.macports.build returned: shell command failed
:debug:build Backtrace: shell command failed
    while executing
"$post $targetname"

[ryandesign (Ryan Carsten Schmidt)]

Has duplicate #28514.

[ryandesign (Ryan Carsten Schmidt)]

(Cc list taken from #28514 and #28501)

[mkae (Marko Käning)]

Cc Me!

[aeevr@…]

Cc Me!

[raramayo (Rodolfo Aramayo)]

Cc Me Too!

[adfernandes (Andrew Fernandes)]

This has been filed at SourceForge as ​this and ​this.

Yes - duplicate bugs, I know... the previous bug got filed between when I started the report and got home to finish it!

[lutz.maibaum@…]

Cc Me!

[SlaunchaMan (Jeff Kelley)]

Cc Me!

[brilthor@…]

Cc Me!

[joergf@…]

Cc Me!

[sean@…]

Cc Me!

[wmiler@…]

Cc Me!

[Veence (Vincent)]

I have committed r76434 that should correct this. Please try again and tell me.

[Veence (Vincent)]

Sorry, there was a typo for ppc archs in r76434. That's corrected in r76435.

[anddam (Andrea D'Amore)]

I can confirm atlas in r76435 builds fine using arch=x86_64 and +gcc44 variant

[Veence (Vincent)]

Please test the runtime (using numpy or scipy, for example), to confirm that libatlas.a is correctly built.

[macports@…]

Confirm that it compiles now arch=x86_64 and gcc44 variant, can't test if it works.

[adfernandes (Andrew Fernandes)]

Hey, vince - great work! I tried tracking this down myself and know, personally, how convoluted the build scripts are. I had almost honed in on a solution similar to yours, but just couldn't quite get it right!

I'll compile first thing and test all the dependencies.

[Veence (Vincent)]

Thanks! ;) That was not a great deal, but I was busy elsewhere and couldn't get down to it before. I have successfully built Atlas on my G5 MacPro with gcc45/Leopard, so ppc64 seems all right too (Numpy tests pass ok). I can't build for ppc 32-bit (G4), so I rely on the goodwill of someone else. Will build i386/x86_64 (gcc45/S.L.) tonight and see.

Now, that's a good lesson. Atlas development snapshots seem to be released without any extensive checks, so we ought to be careful before updating blindly.

[jmroot (Joshua Root)]

If by "updating blindly" you mean committing an update without first checking that it builds, you shouldn't do that for any port.

[Veence (Vincent)]

You're right, and it is not the way I usually do things (because most of the time I detect upgrades before they are asked for). But I "blindly" trusted the initial message and upgraded under the assumption that it had been already tested. Next time, I'll delay by a few hours and see by myself.

[bitmail@…]

Build fails on PPC G4. Not sure if it's related to this bug or due to some other errors. But upgrading fails since 3.9.35, I guess. Installed working version is 3.8.3_4. End of error log file:

:info:build    BEGIN STAGE 2-1-2: CacheEdge DETECTION at 15:00                                                                                                        
:info:build make -f Makefile INSTALL_LOG/atlas_cacheedge.h pre=d 2>&1 | ./xatlas_tee INSTALL_LOG/dMMCACHEEDGE.LOG                                                     
:info:build make[1]: *** [build] Error 255                                                                                                                            
:info:build make: *** [build] Error 2                                                                                                                                 
:info:build shell command " cd "/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_ports_math_atlas/work/atlas-3.9.37/build" &&$
:error:build Target org.macports.build returned: shell command failed (see log for details)                                                                           
:debug:build Backtrace: shell command failed (see log for details)                                                                                                    
    while executing                                                                                                                                                   
"command_exec build"                                                                                                                                                  
    (procedure "portbuild::build_main" line 8)                                                                                                                        
    invoked from within                                                                                                                                               
"$procedure $targetname"                                                                                                                                              
:info:build Warning: the following items did not execute (for atlas): org.macports.destroot org.macports.build                                                        
:notice:build Log for atlas is at: /opt/local/var/macports/logs/_opt_local_var_macports_sources_rsync.macports.org_release_ports_math_atlas/main.log

I can post the full log if requested.

[bitmail@…]

Cc Me!

[Veence (Vincent)]

Yes, please do post the full log. The error you stumble upon is normally unrelated to the one corrected by the patch and, as you say, has been lurking around since the upgrade to the 3.9 branch. But the only way to be 100% sure is to have the complete details. Thanks!

[adfernandes (Andrew Fernandes)]

Replying to vince@…:

You're right, and it is not the way I usually do things (because most of the time I detect upgrades before they are asked for). But I "blindly" trusted the initial message and upgraded under the assumption that it had been already tested. Next time, I'll delay by a few hours and see by myself.

I have to say that I'm with vince on this - the message was my fault. I normally don't submit a patch until I get a clean install. Unfortunately, due to one-too-many terminal windows open, I thought that I had had a clean install. I should have been suspicious that the compile didn't take eight hours.

Anyway - enough kvetching - it's the standard comedy of errors that happens once in a while, and probably is not a huge deal since already-installed-and-working atlas installs will continue to work; it is only the upgrade that will fail.

Am building on SL/gcc45 now.

[a_benali@…]

Tried to build atlas3.9.37 with gcc45 and the install fails.

info:build rm -rf *.o x* config?.out *core*
:debug:build Executing proc-post-org.macports.build-build-0
:info:build Undefined symbols:
:info:build   "_ATL_DecAtomicCount", referenced from:
:info:build       _ATL_dyntlaunch in libatlas.a(ATL_dyntlaunch.o)
:info:build       _ATL_dyntlaunch in libatlas.a(ATL_dyntlaunch.o)
:info:build ld: symbol(s) not found
:info:build shell command "cd /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_ports_math_atlas/work/atlas-3.9.37/build/lib &&  ( test ! -e libatlas.a ||  /usr/bin/ld -arch x86_64 -dynamic -dylib -single_module -dead_strip  -x -all_load -L. -L/opt/local/lib/gcc45/x86_64  -L/opt/local/lib/gcc45 -ldylib1.o  -dylib_install_name /opt/local/lib/libatlas.dylib  libatlas.a -o libatlas.dylib  -lSystem  )" returned error 1
:error:build Target org.macports.build returned: shell command failed (see log for details)
:debug:build Backtrace: shell command failed (see log for details)
    while executing
"$post $targetname"
:info:build Warning: the following items did not execute (for atlas): org.macports.activate org.macports.build org.macports.destroot org.macports.install
:error:build Failed to install atlas
:notice:build Log for atlas is at: /opt/local/var/macports/logs/_opt_local_var_macports_sources_rsync.macports.org_release_ports_math_atlas/main.log

Thanks

[Veence (Vincent)]

Are you sure the Portfile is at revision 76435?

[bitmail@…]

Error on PPC G4

[bitmail@…]

Replying to vince@…:

Yes, please do post the full log. The error you stumble upon is normally unrelated to the one corrected by the patch and, as you say, has been lurking around since the upgrade to the 3.9 branch. But the only way to be 100% sure is to have the complete details. Thanks!

Uploaded main.log with description "Error on PPC G4". Thanks for looking into this!

[a_benali@…]

Replying to vince@…:

Are you sure the Portfile is at revision 76435?

Nope. Just updated the portfile and worked perfect.

Thanks

[anddam (Andrea D'Amore)]

Replying to vince@…:

Please test the runtime (using numpy or scipy, for example), to confirm that libatlas.a is correctly built.

Can you provide a test case? Is just importing numpy enough?

[Veence (Vincent)]

Try this in python:

>>> import numpy
>>> numpy.test('1','10')

Thanks!

[Veence (Vincent)]

Ok, the bug related to ppc is in fact a deeper bug that affects all archs but is kept hidden in ppc64/i386/x86_64. This is in fact a consequence of #28387.

[Veence (Vincent)]

I have committed a new patch and a new Portfile in r76450. Please upgrade and test.

[Veence (Vincent)]

Sorry, try r76451. r76450 had the same typo error that r76434.

[ryandesign (Ryan Carsten Schmidt)]

Replying to vince@…:

Atlas development snapshots seem to be released without any extensive checks, so we ought to be careful before updating blindly.

Why have we updated to a development snapshot at all? MacPorts ports should generally be for stable versions of software, and the latest stable version of atlas remains 3.8.3 ​as far as I can tell.

[ryandesign (Ryan Carsten Schmidt)]

Replying to macports@…:

Undefined symbols:

"_ATL_DecAtomicCount", referenced from:

Has duplicate #28528.

[sewebster@…]

Maybe we can have atlas and atlas-devel or something to avoid constant atlas recompiling? But probably I should just start using -atlas variants...

[sewebster@…]

Cc Me!

[mkae (Marko Käning)]

ATLAS installed fine for me now, if I am not mistaken:

markos-imac:~ marko$ port installed atlas
The following ports are currently installed:
  atlas @3.9.37_0+gcc44 (active)

[Veence (Vincent)]

Ryan, sorry if we upgraded to a development snapshot, but there were so many bugs opened it seemed to be a good idea to bump to a newest version, hoping most of the problems would be solved. Unlike other projects, where development snapshot, though being beta, are very stable and almost of production quality, Atlas releases seem to be highly experimental…

The idea of creating an atlas-devel port could be pondered upon, but it would mean changing every port depending on Atlas. Would it be possible?

[Veence (Vincent)]

Besides, 3.8.3 is about two years old!

[adfernandes (Andrew Fernandes)]

I agree with the decision to use the latest snapshots of atlas. The package was semi-kind-of abandoned for quite a while, and produced incorrect or very, very slow output for a whole slew of modern CPUs and compilers. I think it was important to update.

Anyway - my clean SL port with the latest (r76462) works fine, as does octave (atlas dep) and numpy.

Vince - small patch attached to remove hardcoded version numbers (as per lint).

[bitmail@…]

Small update from my end:

atlas @3.9.37_0+gcc44 did build on PPC G4. Thanks again for fixing that fast!

[Veence (Vincent)]

I'm glad it runs now on ppc too. I am going to run to the Apple store and try to get one of the newest MacBook Pro with SB processors, and then try compiling Atlas on this brand new hardware to see what happens. Thanks for the patch.

[sewebster@…]

I guess this is getting off topic for this bug report, but was the "old" stable atlas actually slower than having no atlas at all for new processors? If so, that's pretty terrible... though I'm not sure if the best idea in that case is to run a devel snapshot, maybe just not using atlas would be better. How can I easily test atlas with macports software to compare atlas vs no-atlas anyway?

[pnorthug@…]

I can't build atlas @3.9.37_0+gcc44 on PPC G5. End of error block:

:info:build    DONE  STAGE 2-1-4 at 14:36
:info:build 
:info:build 
:info:build    BEGIN STAGE 2-1-5: GEMV TUNE at 14:36
:info:build make -f Makefile INSTALL_LOG/dMVNK.sum pre=d 2>&1 | ./xatlas_tee INS
TALL_LOG/dMVNTUNE.LOG
:info:build make[1]: *** [build] Error 255
:info:build make: *** [build] Error 2
:info:build shell command " cd "/opt/local/var/macports/build/_opt_local_var_mac
ports_sources_rsync.macports.org_release_ports_math_atlas/work/atlas-3.9.37/buil
d" && /usr/bin/make build " returned error 2
:error:build Target org.macports.build returned: shell command failed (see log f
or details)
:debug:build Backtrace: shell command failed (see log for details)
    while executing
"command_exec build"
    (procedure "portbuild::build_main" line 8)
    invoked from within
"$procedure $targetname"

[pnorthug@…]

Cc Me!

[Veence (Vincent)]

Please post the full log, this one is too terse to hold anything useable. I'll try again on my ppc G5 Macpro later this morning and see if I can reproduce the failure.

[ryandesign (Ryan Carsten Schmidt)]

@vince: Thanks for your work on this; atlas @3.9.37_1 r76451 built successfully on my Power Mac G4.

@pnorthug: Make sure you have the latest version of the portfile, by using "sudo port selfupdate" again. There were many changes committed recently which may have already fixed that.

[ryandesign (Ryan Carsten Schmidt)]

Replying to ryandesign@…:

@vince: Thanks for your work on this; atlas @3.9.37_1 r76451 built successfully on my Power Mac G4.

Of course I meant atlas @3.9.37_0 since there is no revision 1 yet.

[Veence (Vincent)]

Shall I commit a rev 1 with the small patch added?

[Veence (Vincent)]

Replying to pnorthug@…:

I can't build atlas @3.9.37_0+gcc44 on PPC G5. End of error block:

I have successfully built atlas 3.9.37 on my G5 MacPro this morning, so either you should clean the port and try again, or you are using an out-of-date Portfile version.

[ryandesign (Ryan Carsten Schmidt)]

Replying to vince@…:

Shall I commit a rev 1 with the small patch added?

If you have another update that requires a rebuild, then sure -- with the reservation, of course, that this port is not openmaintainer and lists someone else as the maintainer -- someone who has not yet weighed in on this ticket.

Responding to the earlier comment about using a development version at all, I agree it has been awhile since a stable release of atlas, and if there were problems with the stable release, and this development release fixes them, then ok, let's keep it. I was just surprised that the update was committed by someone who is not this port's maintainer, and there was no ticket or discussion that I could find explaining the decision. If you believe James is not maintaining this port satisfactorily, then you should discuss with him taking it over, or co-maintaining it with him, or asking him to make it openmaintainer, or something. If you cannot reach James, the port abandonment procedure can be followed; it is listed in the Guide. James had some email difficulties (mail bouncing) a few weeks back; if you had trouble contacting him before, maybe try again.

We should also encourage the developers of atlas to make more frequent stable releases so we don't have to keep using unstable versions in the future.

[ryandesign (Ryan Carsten Schmidt)]

Replying to ryandesign@…:

Replying to vince@…:

Shall I commit a rev 1 with the small patch added?

If you have another update that requires a rebuild, then sure

If the small patch you're referring to is the one attached above by adfernandes​, then it can be committed as-is, and does not require a revision bump.

[pnorthug@…]

Replying to ryandesign@…:

@pnorthug: Make sure you have the latest version of the portfile, by using "sudo port selfupdate" again. There were many changes committed recently which may have already fixed that.

I am still getting an error on my G5. I hope I am doing something stupid. My portfile:

$ head /opt/local/var/macports/sources/rsync.macports.org/release/ports/math/atlas/Portfile
# $Id: Portfile 76451 2011-02-23 21:39:15Z vince@macports.org $

PortSystem          1.0
PortGroup           muniversal 1.0

categories          math
name                atlas
version             3.9.37
#revision            4

I did:

$ sudo port selfupdate
$ sudo port clean atlas
$ sudo port clean atlas +gcc44
$ sudo port install atlas +gcc44

Attaching build log.

[Veence (Vincent)]

Replying to pnorthug@…:

Replying to ryandesign@…:

@pnorthug: Make sure you have the latest version of the portfile, by using "sudo port selfupdate" again. There were many changes committed recently which may have already fixed that.

I am still getting an error on my G5. I hope I am doing something stupid. My port file:

You appear to have CFLAGS and CXXFLAGS set for G4 (ppc) not G5 (ppc64). Please check your CFLAGS, CXXFLAGS and F90FLAGS.

[Veence (Vincent)]

Replying to ryandesign@…:

Replying to vince@…:

Shall I commit a rev 1 with the small patch added?

If you have another update that requires a rebuild, then sure -- with the reservation, of course, that this port is not openmaintainer and lists someone else as the maintainer -- someone who has not yet weighed in on this ticket. Responding to the earlier comment about using a development version at all, I agree it has been awhile since a stable release of atlas, and if there were problems with the stable release, and this development release fixes them, then ok, let's keep it. I was just surprised that the update was committed by someone who is not this port's maintainer, and there was no ticket or discussion that I could find explaining the decision. If you believe James is not maintaining this port satisfactorily, then you should discuss with him taking it over, or co-maintaining it with him, or asking him to make it openmaintainer, or something. If you cannot reach James, the port abandonment procedure can be followed; it is listed in the Guide. James had some email difficulties (mail bouncing) a few weeks back; if you had trouble contacting him before, maybe try again.

You're right, I should have followed the proper channels; what I did looks like a putsch, so to speak. When I examined the atlas 3.8.3 port, it seemed both outdated, and there was a lot of bugs opened for a while, and nobody seemed to care about them, except for adding names to the Cc: list. So I decided it was a kind of emergency, I short-circuited the diplomatic way, acted first, and spoke next ;) Now, I claim no ownership on atlas, that was a one shot operation to bring the boat back afloat. If James wants to resume regular maintenance, I'd be delighted.

Finally, I consider the fact that James has not chimed in a bit worrisome (I hope it is just because of a temporary overload)…

[sean@…]

Cc Me!

[ryandesign (Ryan Carsten Schmidt)]

Replying to vince@…:

You appear to have CFLAGS and CXXFLAGS set for G4 (ppc) not G5 (ppc64). Please check your CFLAGS, CXXFLAGS and F90FLAGS.

CFLAGS, CXXFLAGS, F90FLAGS, etc. are not environment variables that the user has direct influence over in MacPorts. Certainly, if the user has set these in their shell environment, MacPorts will ignore them.

Is your concern the fact that the string "-m32" is appearing in these flags? If so, I believe that is the result of "build_arch" being set to "ppc" in macports.conf. "ppc" is in fact the default value of "build_arch" on all PowerPC systems. PowerPC G5 users could certainly change "build_arch" to "ppc64" if they want 64-bit builds, but since that is not the default on any Mac, that configuration is not well-tested.

I see occurrences of "-m64" in the build log as well, and that mix of 32-bit and 64-bit is probably the cause of the relevant error message from the log:

:info:build ld warning: in ATL_dmvnk_b0.o, file is not of required architecture
:info:build ld warning: in ATL_dmvnk_b1.o, file is not of required architecture
:info:build Undefined symbols:
:info:build   "_ATL_UGEMVNK", referenced from:
:info:build       _ATL_UGEMVNK$non_lazy_ptr in ATL_dgemvN.o
:info:build   "_ATL_UGEMVNK_b0", referenced from:
:info:build       _ATL_dgemvN in ATL_dgemvN.o
:info:build       _ATL_UGEMVNK_b0$non_lazy_ptr in ATL_dgemvN.o
:info:build ld: symbol(s) not found

Atlas should not be trying to build itself 64-bit on PowerPC G5 systems unless "build_arch" is "ppc64" in macports.conf. Atlas apparently decided on its own that it wanted to build 64-bit, which is a bug that should be fixed.

Finally, this ticket is enormous, and it is troubling that people keep adding new and unrelated issues to this ticket. First there was the "Undefined symbols: _ATL_DecAtomicCount" error which all users experienced, which was resolved. Then there was the build error on all PowerPC systems, which was resolved. Now there is a new issue only affecting 64-bit PowerPC systems. These should have been three separate tickets.

[adfernandes (Andrew Fernandes)]

Yes, ryandesign is right, this ticket is enormous and I'm going to do my part to make it even more enormous by adding this completely extraneous and content-free comment.

;-)

Seriously, all - atlas is just one of those nasty-wasty ports that tries to figure out too many things and ignores/guesses/plays with compilers and variables and will be nuts to work with for the conceivable future. Trust me, I maintain the boost port, and their custom build system will make you want to drink... heavily. :-)

Hey! I managed to add a comment about yet another unrelated port! A record! :-D

(Sorry all - it's been a long day and I couldn't resist...)

[pnorthug@…]

Replying to ryandesign@…:

Is your concern the fact that the string "-m32" is appearing in these flags? If so, I believe that is the result of "build_arch" being set to "ppc" in macports.conf. "ppc" is in fact the default value of "build_arch" on all PowerPC systems. PowerPC G5 users could certainly change "build_arch" to "ppc64" if they want 64-bit builds, but since that is not the default on any Mac, that configuration is not well-tested.

build_arch in my macports.conf is commented out and I understand that it is by default 'ppc'. I have a default install of macport. I have not fiddled with it and it is a real pleasure to work with (thank you).

[Veence (Vincent)]

Replying to ryandesign@…:

I see occurrences of "-m64" in the build log as well, and that mix of 32-bit and 64-bit is probably the cause of the relevant error message from the log:

:info:build ld warning: in ATL_dmvnk_b0.o, file is not of required architecture
:info:build ld warning: in ATL_dmvnk_b1.o, file is not of required architecture
:info:build Undefined symbols:
:info:build   "_ATL_UGEMVNK", referenced from:
:info:build       _ATL_UGEMVNK$non_lazy_ptr in ATL_dgemvN.o
:info:build   "_ATL_UGEMVNK_b0", referenced from:
:info:build       _ATL_dgemvN in ATL_dgemvN.o
:info:build       _ATL_UGEMVNK_b0$non_lazy_ptr in ATL_dgemvN.o
:info:build ld: symbol(s) not found

You're absolutely right, that's the reason. On my G5, build_arch is set to ppc64, and it builds fine.

Atlas should not be trying to build itself 64-bit on PowerPC G5 systems unless "build_arch" is "ppc64" in macports.conf. Atlas apparently decided on its own that it wanted to build 64-bit, which is a bug that should be fixed.

I can do that, but does it make sense? Atlas is meant to optimize as much as possible the computation of matrix operations. Compiling in 32-bit while superior performance can be obtained by switching to 64-bit seems to me obviously contrary to the philosophy of the port.

[ryandesign (Ryan Carsten Schmidt)]

Individual ports can't just decide to build for some other architecture. There are consequences. MacPorts will record in the registry that it has built the port for ${build_arch}; if that's not true and the port has actually built for some other architecture without telling MacPorts, then the registry would contain inaccurate information.

The registry is used when dealing with dependencies and dependents. If atlas is going to build for ppc64, then all of its dependencies -- gcc44, bzip2, gzip -- need to be built for ppc64 as well. Furthermore, any port that depends on atlas will also need to build ppc64. Basically you'd be forcing all G5 users who have atlas installed to set build_arch to ppc64 and rebuild all ports, which I consider a very drastic thing to make them do, especially considering, as I mentioned above, that ppc64 is not the default build_arch on any Mac, meaning it has not received much testing and there are probably many ports broken under that arch.

I don't know what the advantages for atlas are for building ppc64. I understand that in general ppc64 has few benefits over ppc. Obviously there's the ability to deal with more than 4GB of data in a single process; the only other noticeable difference I'm aware of is that memory addresses take twice as much space to store, so you can fit fewer of them in cache, which could actually hurt performance. This is in stark contrast to the difference between i386 and x86_64; x86_64 adds additional registers and fixes several problems with the legacy i386 architecture, thus offering several speed and efficiency benefits over i386 beyond the ability to address more memory.

Feel free to add a ui_msg to atlas that alerts G5 owners who have build_arch set to ppc that they might have better performance by switching to ppc64. If you insist atlas must build 64-bit on G5s, then you must set configure.build_arch to ppc64 on G5s. However, I don't think it's nice to impose a manual all-port rebuild of an untested build_arch on G5 owners.

[Veence (Vincent)]

Ok Ryan, I will add a ui_msg warning that atlas on G5 should be build 64-bit instead of 32. I think Atlas is precisely smart enough to figure out cache issue with 64-bit addresses: that's precisely its point. Meanwhile, I will patch the Portfile so that it build ppc even if G5 is detected. That would, I think, be worth release a rev.1.

[ryandesign (Ryan Carsten Schmidt)]

No, a revision bump is only warranted if it changes the files installed by the port; this change would not do that. For users of i386, x86_64 and ppc systems, and G5 users who have build_arch already set to ppc64, there would be no change. For users of G5s with build_arch set to ppc, they would not have been able to install the port in the first place.

[martin.osx@…]

@sewebster: Thank you for telling me about -atlas. Live will be so much nicer now without atlas. Never again do i need to look at this for 12h wondering why it takes that long, or if the compile hung:

--->  Computing dependencies for atlas
--->  Fetching atlas
--->  Attempting to fetch atlas3.9.37.tar.bz2 from http://switch.dl.sourceforge.net/math-atlas
--->  Verifying checksum(s) for atlas
--->  Extracting atlas
--->  Applying patches to atlas
--->  Configuring atlas
--->  Building atlas

I will add -atlas to my defaults. Thank you so much.

[jpmasseria@…]

Cc Me!

[Veence (Vincent)]

Replying to pnorthug@…:

Replying to ryandesign@…: I am still getting an error on my G5. I hope I am doing something stupid. My portfile:

[…] r76513 should fix your bug. Please update and try again.

[Veence (Vincent)]

Replying to ryandesign@…:

I don't know what the advantages for atlas are for building ppc64. I understand that in general ppc64 has few benefits over ppc. Obviously there's the ability to deal with more than 4GB of data in a single process; the only other noticeable difference I'm aware of is that memory addresses take twice as much space to store, so you can fit fewer of them in cache, which could actually hurt performance. This is in stark contrast to the difference between i386 and x86_64; x86_64 adds additional registers and fixes several problems with the legacy i386 architecture, thus offering several speed and efficiency benefits over i386 beyond the ability to address more memory.

I will look to see if there is any significant performance increase in floating-point computation between ppc and ppc64. The best way to know would be to compile Atlas using build_arch = ppc, then ppc64 and compare the internal benchmarks!

[pnorthug@…]

Replying to vince@…:

Replying to pnorthug@…:

Replying to ryandesign@…: I am still getting an error on my G5. I hope I am doing something stupid. My portfile:

[…] r76513 should fix your bug. Please update and try again.

It didn't work. I did 'sudo port selfupdate', 'sudo port clean atlas +gcc44', 'sudo port install atlas +gcc44'. My macports.conf is the default. Portfile:

$ head /opt/local/var/macports/sources/rsync.macports.org/release/ports/math/atlas/Portfile
# $Id: Portfile 76513 2011-02-26 21:19:35Z vince@macports.org $

PortSystem          1.0
PortGroup           muniversal 1.0

categories          math
name                atlas
version             3.9.37
#revision            4

Build log attached. Thanks for your help vince.

[pnorthug@…]

using r76513

[Veence (Vincent)]

Replying to pnorthug@…:

It didn't work. I did 'sudo port selfupdate', 'sudo port clean atlas +gcc44', 'sudo port install atlas +gcc44'. My macports.conf is the default. Portfile:

Please retry with r76523.

[Veence (Vincent)]

Or r76524 (which corrects a Tiger incompatibility)

[pnorthug@…]

Replying to vince@…:

Or r76524 (which corrects a Tiger incompatibility)

The build fails in the same place, but the log file is different. Attaching.

[pnorthug@…]

r76524

[Veence (Vincent)]

Try again with r76525. Sorry for this trial and error process, but I have no way to compile for ppc on my G5 Macpro: Gcc45 is ppc64 only. If this lasts, I'll try to get a universal ppc/pcc64 gcc45 so as to be able to make private tests.

[pnorthug@…]

Replying to vince@…:

Try again with r76525. Sorry for this trial and error process, but I have no way to compile for ppc on my G5 Macpro: Gcc45 is ppc64 only. If this lasts, I'll try to get a universal ppc/pcc64 gcc45 so as to be able to make private tests.

No problem at all for me. It failed, attaching log.

[pnorthug@…]

r76525

[Veence (Vincent)]

You're still using the "old" Portfile. Check that instead of -A PPCG4 you get -A 4 in the log.

[pnorthug@…]

Replying to vince@…:

You're still using the "old" Portfile. Check that instead of -A PPCG4 you get -A 4 in the log.

You are right. Sorry about that. It has gotten past the previous fail point, but hasnt finished compiling yet. Will post result tomorrow.

[mas@…]

Cc Me!

[pnorthug@…]

Replying to pnorthug@…:

Replying to vince@…:

You're still using the "old" Portfile. Check that instead of -A PPCG4 you get -A 4 in the log.

Build failed. It is using PPCG4 in places. Build log attached.

[pnorthug@…]

real r76525

[Veence (Vincent)]

Well, the problem is this:

:info:build /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_ports_math_atlas/work/atlas-3.9.37/build/..//src/threads/ATL_DecAtomicCount_ppc.S:27:2: error: #error "Code is not reliable on PPC, don't know why"

!!!

I guess you're the first to stumble on this error because you have a dual PPC G5 whereas anybody else (including me) has a single G4/G5 system. Am I right?

[Veence (Vincent)]

I have further patched the portfile to disable threading on ppc arch (there is unfortunately no other way out at this point). Please update to r76544 and try again.

[trog24 (Frank J. R. Hanstick)]

I too encountered the same error on a Quicksilver PowerPC G4 system via:

sudo port upgrade installed.

Both an uncleaned retry and a cleaned retry resulted in a repeat of the same error. Attached will be the log.

[trog24 (Frank J. R. Hanstick)]

Atlas log

[Veence (Vincent)]

The log shows the same bug as the previous one. Please upgrade to r76544 and retry.

[pnorthug@…]

Replying to vince@…:

I have further patched the portfile to disable threading on ppc arch (there is unfortunately no other way out at this point). Please update to r76544 and try again.

This one built for me. Please let me know if you need more testing. I am going to try to switch to a ppc64 macports distribution, but will keep a copy of this one.

[Veence (Vincent)]

I think it's worth switching to ppc64 especially if you do a lot of maths. G5 has a second AltiVec unit that can switch operations and handle directly complex number calculations. While it may not boost the overall performance by a factor of 2 or 3, why not use it since it is there anyhow? Besides, Ryan rightly pointed out this might have cache side effects, but Atlas precisely is there to take this into account.

[Veence (Vincent)]

Apparently, this bug is fixed. I close it. Please file another ticket if you detect subsequent failures.

[dershow]

I am not able to get the build to work on a dual G4 machine. Although it is now building fine for me on a dual g5 machine.

[jmroot (Joshua Root)]

File a new ticket as requested in comment:88.