#28512 closed defect (fixed)
atlas: undefined symbols _ATL_DecAtomicCount
Reported by: | macports@… | Owned by: | jameskyle@… |
---|---|---|---|
Priority: | Normal | Milestone: | |
Component: | ports | Version: | 1.9.99 |
Keywords: | Cc: | sonny@…, adfernandes (Andrew Fernandes), Veence (Vincent), dershow, Garfield-fr (Bertrand Zuchuat), f.calboli@…, anddam (Andrea D'Amore), ryandesign (Ryan Carsten Schmidt), mkae (Marko Käning), aeevr@…, lutz.maibaum@…, SlaunchaMan (Jeff Kelley), brilthor@…, wmiler@…, bitmail@…, sewebster@…, pnorthug@…, jpmasseria@…, mas@… | |
Port: | atlas |
Description (last modified by ryandesign (Ryan Carsten Schmidt))
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"
Attachments (8)
Change History (99)
comment:3 Changed 14 years ago by ryandesign (Ryan Carsten Schmidt)
Description: | modified (diff) |
---|
comment:4 Changed 14 years ago by ryandesign (Ryan Carsten Schmidt)
comment:5 Changed 14 years ago by ryandesign (Ryan Carsten Schmidt)
Cc: | sonny@… adfernandes@… vince@… dersh@… bertrand.zuchuat@… f.calboli@… and.damore@… ryandesign@… added |
---|---|
Owner: | changed from macports-tickets@… to jameskyle@… |
comment:6 Changed 14 years ago by ryandesign (Ryan Carsten Schmidt)
comment:8 Changed 14 years ago by adfernandes (Andrew Fernandes)
comment:15 follow-ups: 17 19 Changed 14 years ago by Veence (Vincent)
I have committed r76434 that should correct this. Please try again and tell me.
comment:16 Changed 14 years ago by Veence (Vincent)
comment:17 Changed 14 years ago by anddam (Andrea D'Amore)
I can confirm atlas in r76435 builds fine using arch=x86_64 and +gcc44 variant
comment:18 follow-up: 32 Changed 14 years ago by Veence (Vincent)
Please test the runtime (using numpy or scipy, for example), to confirm that libatlas.a is correctly built.
comment:19 Changed 14 years ago by macports@…
Confirm that it compiles now arch=x86_64 and gcc44 variant, can't test if it works.
comment:20 Changed 14 years ago by 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.
comment:21 follow-up: 37 Changed 14 years ago by 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.
comment:22 Changed 14 years ago by 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.
comment:23 follow-up: 27 Changed 14 years ago by 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.
comment:24 Changed 14 years ago by 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.
comment:26 follow-up: 30 Changed 14 years ago by 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!
comment:27 Changed 14 years ago by 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.
comment:28 Changed 14 years ago by 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
comment:29 follow-up: 31 Changed 14 years ago by Veence (Vincent)
Are you sure the Portfile is at revision 76435?
comment:30 Changed 14 years ago by 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!
comment:31 Changed 14 years ago by a_benali@…
Replying to vince@…:
Are you sure the Portfile is at revision 76435?
Nope. Just updated the portfile and worked perfect.
Thanks
comment:32 Changed 14 years ago by 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?
comment:33 Changed 14 years ago by Veence (Vincent)
Try this in python:
>>> import numpy >>> numpy.test('1','10')
Thanks!
comment:34 Changed 14 years ago by 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.
comment:35 Changed 14 years ago by Veence (Vincent)
I have committed a new patch and a new Portfile in r76450. Please upgrade and test.
comment:36 Changed 14 years ago by Veence (Vincent)
comment:37 Changed 14 years ago by 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.
comment:38 Changed 14 years ago by ryandesign (Ryan Carsten Schmidt)
Replying to macports@…:
Undefined symbols:
"_ATL_DecAtomicCount", referenced from:
Has duplicate #28528.
comment:39 Changed 14 years ago by 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...
comment:41 Changed 14 years ago by 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)
comment:42 Changed 14 years ago by 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?
comment:44 Changed 14 years ago by 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).
Changed 14 years ago by adfernandes (Andrew Fernandes)
Attachment: | Portfile.diff added |
---|
comment:45 Changed 14 years ago by bitmail@…
Small update from my end:
atlas @3.9.37_0+gcc44 did build on PPC G4. Thanks again for fixing that fast!
comment:46 Changed 14 years ago by 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.
comment:47 Changed 14 years ago by 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?
comment:48 follow-up: 54 Changed 14 years ago by 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"
comment:50 Changed 14 years ago by 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.
comment:51 follow-ups: 52 57 Changed 14 years ago by 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.
comment:52 Changed 14 years ago by 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.
comment:53 follow-up: 55 Changed 14 years ago by Veence (Vincent)
Shall I commit a rev 1 with the small patch added?
comment:54 Changed 14 years ago by 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.
comment:55 follow-ups: 56 59 Changed 14 years ago by 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.
comment:56 Changed 14 years ago by 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.
comment:57 follow-ups: 58 70 Changed 14 years ago by 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.
Changed 14 years ago by pnorthug@…
Attachment: | main.2.log added |
---|
comment:58 follow-up: 61 Changed 14 years ago by 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.
comment:59 Changed 14 years ago by 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)…
comment:61 follow-ups: 63 64 Changed 14 years ago by 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.
comment:62 Changed 14 years ago by 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...)
comment:63 Changed 14 years ago by 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).
comment:64 Changed 14 years ago by 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.
comment:65 follow-up: 71 Changed 14 years ago by 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.
comment:66 Changed 14 years ago by 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.
comment:67 Changed 14 years ago by 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.
comment:68 Changed 14 years ago by 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.
comment:70 follow-up: 72 Changed 14 years ago by 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.
comment:71 Changed 14 years ago by 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!
comment:72 follow-up: 73 Changed 14 years ago by 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.
comment:73 Changed 14 years ago by 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.
comment:74 follow-up: 75 Changed 14 years ago by Veence (Vincent)
Or r76524 (which corrects a Tiger incompatibility)
comment:75 Changed 14 years ago by pnorthug@…
comment:76 follow-up: 77 Changed 14 years ago by 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.
comment:77 Changed 14 years ago by 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.
comment:78 follow-up: 79 Changed 14 years ago by Veence (Vincent)
You're still using the "old" Portfile. Check that instead of -A PPCG4 you get -A 4 in the log.
comment:79 follow-up: 81 Changed 14 years ago by 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.
comment:81 Changed 14 years ago by 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.
comment:82 Changed 14 years ago by 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?
comment:83 follow-up: 86 Changed 14 years ago by 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.
comment:84 Changed 14 years ago by 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.
comment:85 Changed 14 years ago by Veence (Vincent)
The log shows the same bug as the previous one. Please upgrade to r76544 and retry.
comment:86 Changed 14 years ago by 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.
comment:87 Changed 14 years ago by 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.
comment:88 Changed 14 years ago by Veence (Vincent)
Resolution: | → fixed |
---|---|
Status: | new → closed |
Apparently, this bug is fixed. I close it. Please file another ticket if you detect subsequent failures.
comment:89 Changed 14 years ago by dershow
Resolution: | fixed |
---|---|
Status: | closed → reopened |
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.
comment:90 Changed 14 years ago by jmroot (Joshua Root)
Resolution: | → fixed |
---|---|
Status: | reopened → closed |
File a new ticket as requested in comment:88.
comment:91 Changed 14 years ago by ryandesign (Ryan Carsten Schmidt)
Summary: | atlas wont compile → atlas: undefined symbols _ATL_DecAtomicCount |
---|
Has duplicate #28514.