Opened 10 years ago

Closed 10 years ago

Last modified 10 years ago

#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 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 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)

main.log (864.4 KB) - added by bitmail@… 10 years ago.
Error on PPC G4
Portfile.diff (761 bytes) - added by adfernandes (Andrew Fernandes) 10 years ago.
main.2.log (1.5 MB) - added by pnorthug@… 10 years ago.
main.3.log (1.5 MB) - added by pnorthug@… 10 years ago.
using r76513
main.4.log (1.5 MB) - added by pnorthug@… 10 years ago.
r76524
main.5.log (1.5 MB) - added by pnorthug@… 10 years ago.
r76525
main.6.log (5.6 MB) - added by pnorthug@… 10 years ago.
real r76525
main.7.log (5.6 MB) - added by trog24 (Frank J. R. Hanstick) 10 years ago.
Atlas log

Change History (99)

comment:3 Changed 10 years ago by ryandesign (Ryan Schmidt)

Description: modified (diff)

comment:4 Changed 10 years ago by ryandesign (Ryan Schmidt)

Has duplicate #28514.

comment:5 Changed 10 years ago by ryandesign (Ryan Schmidt)

Cc: sonny@… adfernandes@… vince@… dersh@… bertrand.zuchuat@… f.calboli@… and.damore@… ryandesign@… added
Owner: changed from macports-tickets@… to jameskyle@…

comment:6 Changed 10 years ago by ryandesign (Ryan Schmidt)

(Cc list taken from #28514 and #28501)

comment:7 Changed 10 years ago by mkae (Marko Käning)

Cc: mk@… added

Cc Me!

comment:8 Changed 10 years ago by aeevr@…

Cc: aeevr@… added

Cc Me!

comment:7 Changed 10 years ago by raramayo (Rodolfo Aramayo)

Cc Me Too!

comment:8 Changed 10 years ago by 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!

comment:9 Changed 10 years ago by lutz.maibaum@…

Cc: lutz.maibaum@… added

Cc Me!

comment:10 Changed 10 years ago by SlaunchaMan (Jeff Kelley)

Cc: SlaunchaMan@… added

Cc Me!

comment:11 Changed 10 years ago by brilthor@…

Cc: brilthor@… added

Cc Me!

comment:12 Changed 10 years ago by joergf@…

Cc Me!

comment:13 Changed 10 years ago by sean@…

Cc: sean@… added

Cc Me!

comment:14 Changed 10 years ago by wmiler@…

Cc: wmiler@… added

Cc Me!

comment:15 Changed 10 years ago by Veence (Vincent)

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

comment:16 Changed 10 years ago by Veence (Vincent)

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

comment:17 in reply to:  15 Changed 10 years ago by anddam (Andrea D'Amore)

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

comment:18 Changed 10 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 in reply to:  15 Changed 10 years ago by macports@…

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

comment:20 Changed 10 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 Changed 10 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 10 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 Changed 10 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 10 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:25 Changed 10 years ago by bitmail@…

Cc: bitmail@… added

Cc Me!

comment:26 Changed 10 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 in reply to:  23 Changed 10 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 10 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 Changed 10 years ago by Veence (Vincent)

Are you sure the Portfile is at revision 76435?

Changed 10 years ago by bitmail@…

Attachment: main.log added

Error on PPC G4

comment:30 in reply to:  26 Changed 10 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 in reply to:  29 Changed 10 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 in reply to:  18 Changed 10 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 10 years ago by Veence (Vincent)

Try this in python:

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

Thanks!

comment:34 Changed 10 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 10 years ago by Veence (Vincent)

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

comment:36 Changed 10 years ago by Veence (Vincent)

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

comment:37 in reply to:  21 Changed 10 years ago by ryandesign (Ryan 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 in reply to:  description Changed 10 years ago by ryandesign (Ryan Schmidt)

Replying to macports@…:

Undefined symbols:

"_ATL_DecAtomicCount", referenced from:

Has duplicate #28528.

comment:39 Changed 10 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:40 Changed 10 years ago by sewebster@…

Cc: sewebster@… added

Cc Me!

comment:41 Changed 10 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 10 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:43 Changed 10 years ago by Veence (Vincent)

Besides, 3.8.3 is about two years old!

comment:44 Changed 10 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 10 years ago by adfernandes (Andrew Fernandes)

Attachment: Portfile.diff added

comment:45 Changed 10 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 10 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 10 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 Changed 10 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:49 Changed 10 years ago by pnorthug@…

Cc: pnorthug@… added

Cc Me!

comment:50 Changed 10 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 Changed 10 years ago by ryandesign (Ryan 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 in reply to:  51 Changed 10 years ago by ryandesign (Ryan 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 Changed 10 years ago by Veence (Vincent)

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

comment:54 in reply to:  48 Changed 10 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 in reply to:  53 ; Changed 10 years ago by ryandesign (Ryan 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 in reply to:  55 Changed 10 years ago by ryandesign (Ryan 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 in reply to:  51 ; Changed 10 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 10 years ago by pnorthug@…

Attachment: main.2.log added

comment:58 in reply to:  57 ; Changed 10 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 in reply to:  55 Changed 10 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:60 Changed 10 years ago by sean@…

Cc: sean@… removed

Cc Me!

comment:61 in reply to:  58 ; Changed 10 years ago by ryandesign (Ryan 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 10 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 in reply to:  61 Changed 10 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 in reply to:  61 Changed 10 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 Changed 10 years ago by ryandesign (Ryan 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 10 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 10 years ago by ryandesign (Ryan 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 10 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:69 Changed 10 years ago by jpmasseria@…

Cc: jpmasseria@… added

Cc Me!

comment:70 in reply to:  57 ; Changed 10 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 in reply to:  65 Changed 10 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 in reply to:  70 ; Changed 10 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.

Changed 10 years ago by pnorthug@…

Attachment: main.3.log added

using r76513

comment:73 in reply to:  72 Changed 10 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 Changed 10 years ago by Veence (Vincent)

Or r76524 (which corrects a Tiger incompatibility)

comment:75 in reply to:  74 Changed 10 years ago by 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.

Changed 10 years ago by pnorthug@…

Attachment: main.4.log added

comment:76 Changed 10 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 in reply to:  76 Changed 10 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.

Changed 10 years ago by pnorthug@…

Attachment: main.5.log added

comment:78 Changed 10 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 in reply to:  78 ; Changed 10 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:80 Changed 10 years ago by mas@…

Cc: mas@… added

Cc Me!

comment:81 in reply to:  79 Changed 10 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.

Changed 10 years ago by pnorthug@…

Attachment: main.6.log added

real r76525

comment:82 Changed 10 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 Changed 10 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 10 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.

Changed 10 years ago by trog24 (Frank J. R. Hanstick)

Attachment: main.7.log added

Atlas log

comment:85 Changed 10 years ago by Veence (Vincent)

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

comment:86 in reply to:  83 Changed 10 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 10 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 10 years ago by Veence (Vincent)

Resolution: fixed
Status: newclosed

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

comment:89 Changed 10 years ago by dershow

Resolution: fixed
Status: closedreopened

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 10 years ago by jmroot (Joshua Root)

Resolution: fixed
Status: reopenedclosed

File a new ticket as requested in comment:88.

comment:91 Changed 10 years ago by ryandesign (Ryan Schmidt)

Summary: atlas wont compileatlas: undefined symbols _ATL_DecAtomicCount
Note: See TracTickets for help on using tickets.