From: Alexander H. <ale...@gm...> - 2012-06-02 15:37:48
|
At the point where libatlas.dylib is getting built I get the following error: ... Undefined symbols: "_ATL_FreeAtomicCount", referenced from: _ATL_FreeGlobalAtomicCount in ATL_FreeGlobalAtomicCount.o "restFP", referenced from: _ATL_cCtrsmKL in ATL_cCtrsmKL.o <bunch of other .o> "saveFP", referenced from: _ATL_cCtrsmKL in ATL_cCtrsmKL.o <bunch of other .o> "_ATL_ResetAtomicCount", referenced from: _ATL_ResetGlobalAtomicCount in ATL_ResetGlobalAtomicCount.o "restGPR", referenced from: _ATL_cCtrsmKL in ATL_cCtrsmKL.o <bunch of other .o> "_ATL_DecAtomicCount", referenced from: _ATL_DecGlobalAtomicCount in ATL_DecGlobalAtomicCount.o "_ATL_SetAtomicCount", referenced from: _ATL_SetGlobalAtomicCount in ATL_SetGlobalAtomicCount.o "restGPRx", referenced from: _ATL_DecGlobalAtomicCount in ATL_DecGlobalAtomicCount.o <bunch of other .o> "saveGPR", referenced from: _ATL_DecGlobalAtomicCount in ATL_DecGlobalAtomicCount.o <bunch of other .o> ld: symbol(s) not found ... Package manager version: 0.32.99.git Distribution version: selfupdate-cvs Thu May 31 09:27:48 2012, 10.5, powerpc Trees: stable/main stable/crypto unstable/main unstable/crypto local/main local/injected local/common local/10.4 Xcode: 3.1.4 Max. Fink build jobs: 1 This machine is a G4. -- Alexander Hansen, Ph.D. Fink User Liaison http://finkakh.wordpress.com/2012/02/21/got-job/ |
From: Jack H. <ho...@br...> - 2012-06-02 16:00:36
|
On Sat, Jun 02, 2012 at 08:37:37AM -0700, Alexander Hansen wrote: > At the point where libatlas.dylib is getting built I get the following > error: > > ... > Undefined symbols: > "_ATL_FreeAtomicCount", referenced from: > > _ATL_FreeGlobalAtomicCount in ATL_FreeGlobalAtomicCount.o > "restFP", referenced from: > _ATL_cCtrsmKL in ATL_cCtrsmKL.o > > <bunch of other .o> > > "saveFP", referenced from: > _ATL_cCtrsmKL in ATL_cCtrsmKL.o > > <bunch of other .o> > > "_ATL_ResetAtomicCount", referenced from: > _ATL_ResetGlobalAtomicCount in ATL_ResetGlobalAtomicCount.o > "restGPR", referenced from: > _ATL_cCtrsmKL in ATL_cCtrsmKL.o > > <bunch of other .o> > > "_ATL_DecAtomicCount", referenced from: > _ATL_DecGlobalAtomicCount in ATL_DecGlobalAtomicCount.o > "_ATL_SetAtomicCount", referenced from: > _ATL_SetGlobalAtomicCount in ATL_SetGlobalAtomicCount.o > "restGPRx", referenced from: > _ATL_DecGlobalAtomicCount in ATL_DecGlobalAtomicCount.o > > <bunch of other .o> > > "saveGPR", referenced from: > _ATL_DecGlobalAtomicCount in ATL_DecGlobalAtomicCount.o > > <bunch of other .o> > > ld: symbol(s) not found > > ... > > Package manager version: 0.32.99.git > Distribution version: selfupdate-cvs Thu May 31 09:27:48 2012, 10.5, powerpc > Trees: stable/main stable/crypto unstable/main unstable/crypto > local/main local/injected local/common local/10.4 > Xcode: 3.1.4 > Max. Fink build jobs: 1 > > This machine is a G4. > I thought another package had a similar error in the past six months. You should check with fangism. Also try reducing the gcc47-compiler dependency and usage to gcc46-compiler on powerpc. There was a rewrite of how the FPR routines are used on ppc darwin in 4.7... http://old.nabble.com/-Patch-Darwin-PPC--implement-out-of-line-FPR-GPR-saves-restores.-td32651058.html Also, I notice that MacPorts uses -Fa alg '-fPIC -m32 -force_cpusubtype_ALL' on the configure options for atlas. Since the ChangeLog for the gcc patch mentions that option it might be significant that we aren't using in on fink for ppc. Jack > -- > Alexander Hansen, Ph.D. > Fink User Liaison > http://finkakh.wordpress.com/2012/02/21/got-job/ |
From: Alexander H. <ale...@gm...> - 2012-06-02 16:12:01
|
On 6/2/12 9:00 AM, Jack Howarth wrote: > On Sat, Jun 02, 2012 at 08:37:37AM -0700, Alexander Hansen wrote: >> At the point where libatlas.dylib is getting built I get the following >> error: >> >> ... >> Undefined symbols: >> "_ATL_FreeAtomicCount", referenced from: >> >> _ATL_FreeGlobalAtomicCount in ATL_FreeGlobalAtomicCount.o >> "restFP", referenced from: >> _ATL_cCtrsmKL in ATL_cCtrsmKL.o >> >> <bunch of other .o> >> >> "saveFP", referenced from: >> _ATL_cCtrsmKL in ATL_cCtrsmKL.o >> >> <bunch of other .o> >> >> "_ATL_ResetAtomicCount", referenced from: >> _ATL_ResetGlobalAtomicCount in ATL_ResetGlobalAtomicCount.o >> "restGPR", referenced from: >> _ATL_cCtrsmKL in ATL_cCtrsmKL.o >> >> <bunch of other .o> >> >> "_ATL_DecAtomicCount", referenced from: >> _ATL_DecGlobalAtomicCount in ATL_DecGlobalAtomicCount.o >> "_ATL_SetAtomicCount", referenced from: >> _ATL_SetGlobalAtomicCount in ATL_SetGlobalAtomicCount.o >> "restGPRx", referenced from: >> _ATL_DecGlobalAtomicCount in ATL_DecGlobalAtomicCount.o >> >> <bunch of other .o> >> >> "saveGPR", referenced from: >> _ATL_DecGlobalAtomicCount in ATL_DecGlobalAtomicCount.o >> >> <bunch of other .o> >> >> ld: symbol(s) not found >> >> ... >> >> Package manager version: 0.32.99.git >> Distribution version: selfupdate-cvs Thu May 31 09:27:48 2012, 10.5, powerpc >> Trees: stable/main stable/crypto unstable/main unstable/crypto >> local/main local/injected local/common local/10.4 >> Xcode: 3.1.4 >> Max. Fink build jobs: 1 >> >> This machine is a G4. >> > > I thought another package had a similar error in the past six months. You > should check with fangism. No need. It was me, and the report was for Octave on powerpc. The result was that I abandoned the use of gcc47 for Octave on powerpc because I wanted something that actually works. Also try reducing the gcc47-compiler dependency > and usage to gcc46-compiler on powerpc. There was a rewrite of how the FPR routines > are used on ppc darwin in 4.7... > > http://old.nabble.com/-Patch-Darwin-PPC--implement-out-of-line-FPR-GPR-saves-restores.-td32651058.html > > Also, I notice that MacPorts uses -Fa alg '-fPIC -m32 -force_cpusubtype_ALL' on the configure options > for atlas. Since the ChangeLog for the gcc patch mentions that option it might be significant that we > aren't using in on fink for ppc. > Jack > Screw it, I'm going back to gcc46 for now. I don't feel inclined to twiddle configure options for something that takes me 3 days to get a failure when the package is currently BROKEN. -- Alexander Hansen, Ph.D. Fink User Liaison http://finkakh.wordpress.com/2012/02/21/got-job/ |
From: Alexander H. <ale...@gm...> - 2012-06-04 18:11:46
|
On 6/2/12 8:37 AM, Alexander Hansen wrote: > At the point where libatlas.dylib is getting built I get the following > error: > > ... > Undefined symbols: > "_ATL_FreeAtomicCount", referenced from: > > _ATL_FreeGlobalAtomicCount in ATL_FreeGlobalAtomicCount.o > "restFP", referenced from: > _ATL_cCtrsmKL in ATL_cCtrsmKL.o > > <bunch of other .o> > > "saveFP", referenced from: > _ATL_cCtrsmKL in ATL_cCtrsmKL.o > > <bunch of other .o> > > "_ATL_ResetAtomicCount", referenced from: > _ATL_ResetGlobalAtomicCount in ATL_ResetGlobalAtomicCount.o > "restGPR", referenced from: > _ATL_cCtrsmKL in ATL_cCtrsmKL.o > > <bunch of other .o> > > "_ATL_DecAtomicCount", referenced from: > _ATL_DecGlobalAtomicCount in ATL_DecGlobalAtomicCount.o > "_ATL_SetAtomicCount", referenced from: > _ATL_SetGlobalAtomicCount in ATL_SetGlobalAtomicCount.o > "restGPRx", referenced from: > _ATL_DecGlobalAtomicCount in ATL_DecGlobalAtomicCount.o > > <bunch of other .o> > > "saveGPR", referenced from: > _ATL_DecGlobalAtomicCount in ATL_DecGlobalAtomicCount.o > > <bunch of other .o> > > ld: symbol(s) not found > > ... > > Package manager version: 0.32.99.git > Distribution version: selfupdate-cvs Thu May 31 09:27:48 2012, 10.5, powerpc > Trees: stable/main stable/crypto unstable/main unstable/crypto > local/main local/injected local/common local/10.4 > Xcode: 3.1.4 > Max. Fink build jobs: 1 > > This machine is a G4. > In switching to gcc46 I got rid of the rest* and save* errors. However, I'm still left with: /sw/src/fink.build/atlas-3.9.76-4/SHAR_bld/lib ld -arch ppc -dynamic -dylib -single_module -dead_strip_dylibs -dead_strip -x <bunch of .o files> -L. -L/sw/lib/gcc4.6/lib -ldylib1.o -dylib_install_name /sw/lib/libatlas.dylib -o libatlas.dylib -lSystem Undefined symbols: "_ATL_FreeAtomicCount", referenced from: _ATL_FreeGlobalAtomicCount in ATL_FreeGlobalAtomicCount.o "_ATL_ResetAtomicCount", referenced from: _ATL_ResetGlobalAtomicCount in ATL_ResetGlobalAtomicCount.o "_ATL_DecAtomicCount", referenced from: _ATL_DecGlobalAtomicCount in ATL_DecGlobalAtomicCount.o "_ATL_SetAtomicCount", referenced from: _ATL_SetGlobalAtomicCount in ATL_SetGlobalAtomicCount.o ld: symbol(s) not found -- Alexander Hansen, Ph.D. Fink User Liaison http://finkakh.wordpress.com/2012/02/21/got-job/ |
From: Jack H. <ho...@br...> - 2012-06-05 18:03:55
|
Alexander, Do you have a previous build of an earlier altas installed? A google on ATL_FreeAtomicCount undefined produced... http://trac.sagemath.org/sage_trac/ticket/12349 Jack |
From: Alexander H. <ale...@gm...> - 2012-06-05 18:15:48
|
On 6/5/12 11:03 AM, Jack Howarth wrote: > Alexander, > Do you have a previous build of an earlier altas installed? A google on ATL_FreeAtomicCount undefined > produced... > > http://trac.sagemath.org/sage_trac/ticket/12349 > > Jack Yes, since the new packaging didn't explicitly forbid it in any way. -- Alexander Hansen, Ph.D. Fink User Liaison http://finkakh.wordpress.com/2012/02/21/got-job/ |
From: Alexander H. <ale...@gm...> - 2012-06-06 15:20:44
|
On 6/5/12 11:15 AM, Alexander Hansen wrote: > On 6/5/12 11:03 AM, Jack Howarth wrote: >> Alexander, >> Do you have a previous build of an earlier altas installed? A google on ATL_FreeAtomicCount undefined >> produced... >> >> http://trac.sagemath.org/sage_trac/ticket/12349 >> >> Jack > > > Yes, since the new packaging didn't explicitly forbid it in any way. > I don't think a previous atlas is too likely to be causing the problem since I was able to update from 3.9.11 to 3.9.76 on 10.5/i386. I got the same failure again on PowerPC with the change that I made. While I try what Jack suggested in IRC (adding -t0 to the mflags), I'm going to roll back to 3.9.11 for powerpc in the distribution so that we don't leave folks stranded with a broken package. -- Alexander Hansen, Ph.D. Fink User Liaison http://finkakh.wordpress.com/2012/02/21/got-job/ |
From: Alexander H. <ale...@gm...> - 2012-06-06 15:20:24
|
On 6/5/12 11:15 AM, Alexander Hansen wrote: > On 6/5/12 11:03 AM, Jack Howarth wrote: >> Alexander, >> Do you have a previous build of an earlier altas installed? A google on ATL_FreeAtomicCount undefined >> produced... >> >> http://trac.sagemath.org/sage_trac/ticket/12349 >> >> Jack > > > Yes, since the new packaging didn't explicitly forbid it in any way. > I don't think a previous atlas is too likely to be causing the problem since I was able to update from 3.9.11 to 3.9.76 on 10.5/i386. I got the same failure again on PowerPC with the change that I made. While I try what Jack suggested in IRC (adding -t0) to the mflags, I'm going to roll back to 3.9.11 for powerpc in the distribution so that we don't leave folks stranded with a broken package. -- Alexander Hansen, Ph.D. Fink User Liaison http://finkakh.wordpress.com/2012/02/21/got-job/ |
From: jfm <jf...@co...> - 2012-06-06 17:02:41
|
On Jun 6, 2012, at 5:20 PM, Alexander Hansen wrote: > On 6/5/12 11:15 AM, Alexander Hansen wrote: >> On 6/5/12 11:03 AM, Jack Howarth wrote: >>> Alexander, >>> Do you have a previous build of an earlier altas installed? A google on ATL_FreeAtomicCount undefined >>> produced... >>> >>> http://trac.sagemath.org/sage_trac/ticket/12349 >>> >>> Jack >> >> >> Yes, since the new packaging didn't explicitly forbid it in any way. >> > > I don't think a previous atlas is too likely to be causing the problem > since I was able to update from 3.9.11 to 3.9.76 on 10.5/i386. Right. If you look at your link command in this thread, this looks impossible. Sounds much more likely that those .o files were for some reason not made. Trivial to look into your libatlas.a to see if they are there... (But I can't look into your builddir.) It may be useful to send a bug report upstream, since upstream's G4 is dead, so no more testing on G4 ... (cf. http://www.cs.utsa.edu/~whaley/ATL310/) > > I got the same failure again on PowerPC with the change that I made. which change ? > > While I try what Jack suggested in IRC (adding -t0) to the mflags, what is this, and why should it help ?? JF |
From: Alexander H. <ale...@gm...> - 2012-06-06 16:41:46
|
On 6/6/12 9:37 AM, jfm wrote: > > On Jun 6, 2012, at 5:20 PM, Alexander Hansen wrote: > >> On 6/5/12 11:15 AM, Alexander Hansen wrote: >>> On 6/5/12 11:03 AM, Jack Howarth wrote: >>>> Alexander, >>>> Do you have a previous build of an earlier altas installed? A google on ATL_FreeAtomicCount undefined >>>> produced... >>>> >>>> http://trac.sagemath.org/sage_trac/ticket/12349 >>>> >>>> Jack >>> >>> >>> Yes, since the new packaging didn't explicitly forbid it in any way. >>> >> >> I don't think a previous atlas is too likely to be causing the problem >> since I was able to update from 3.9.11 to 3.9.76 on 10.5/i386. > Right. If you look at your link command in this thread, this looks impossible. > Sounds much more likely that those .o files were for some reason not made. > Trivial to look into your libatlas.a to see if they are there... (But I can't look > into your builddir.) > It may be useful to send a bug report upstream, since upstream's G4 is dead, > so no more testing on G4 ... (cf. http://www.cs.utsa.edu/~whaley/ATL310/) >> >> I got the same failure again on PowerPC with the change that I made. > which change ? >> Sorry, I should have said. :-) It was to use "-Si archdef 0" in the ConfigureParams, since that's what David Fang was doing in his experimental tree for PowerPC builds. >> While I try what Jack suggested in IRC (adding -t0) to the mflags, > > what is this, and why should it help ?? > > JF > I think it turns off threading. He got it from the powerpc section of Macports' atlas Portfile. -- Alexander Hansen, Ph.D. Fink User Liaison http://finkakh.wordpress.com/2012/02/21/got-job/ |
From: Jack H. <ho...@br...> - 2012-06-06 16:55:35
|
On Wed, Jun 06, 2012 at 09:41:32AM -0700, Alexander Hansen wrote: > On 6/6/12 9:37 AM, jfm wrote: > > > > On Jun 6, 2012, at 5:20 PM, Alexander Hansen wrote: > > > >> On 6/5/12 11:15 AM, Alexander Hansen wrote: > >>> On 6/5/12 11:03 AM, Jack Howarth wrote: > >>>> Alexander, > >>>> Do you have a previous build of an earlier altas installed? A google on ATL_FreeAtomicCount undefined > >>>> produced... > >>>> > >>>> http://trac.sagemath.org/sage_trac/ticket/12349 > >>>> > >>>> Jack > >>> > >>> > >>> Yes, since the new packaging didn't explicitly forbid it in any way. > >>> > >> > >> I don't think a previous atlas is too likely to be causing the problem > >> since I was able to update from 3.9.11 to 3.9.76 on 10.5/i386. > > Right. If you look at your link command in this thread, this looks impossible. > > Sounds much more likely that those .o files were for some reason not made. > > Trivial to look into your libatlas.a to see if they are there... (But I can't look > > into your builddir.) > > It may be useful to send a bug report upstream, since upstream's G4 is dead, > > so no more testing on G4 ... (cf. http://www.cs.utsa.edu/~whaley/ATL310/) > >> > >> I got the same failure again on PowerPC with the change that I made. > > which change ? > >> > > Sorry, I should have said. :-) > > It was to use "-Si archdef 0" in the ConfigureParams, since that's what > David Fang was doing in his experimental tree for PowerPC builds. > > >> While I try what Jack suggested in IRC (adding -t0) to the mflags, > > > > what is this, and why should it help ?? > > > > JF > > > > I think it turns off threading. He got it from the powerpc section of > Macports' atlas Portfile. Alexander, Testing the following change to the current atlas.info on 10.5 ppc darwin... --- /sw/fink/10.4/stable/main/finkinfo/sci/atlas.info 2012-06-05 15:16:34.000000000 -0400 +++ atlas.info 2012-06-05 15:42:54.000000000 -0400 @@ -1,7 +1,6 @@ Package: atlas Version: 3.9.76 -Revision: 3 -Architecture: i386, x86_64 +Revision: 5 Description: Portable optimal linear algebra software DescDetail: << The current version provides a complete BLAS and LAPACK API. @@ -106,7 +105,7 @@ then mflags="$mflags -m32 -mfpmath=sse" else if [ "%m" = 'x86_64' ] then mflags="$mflags -m64 -mfpmath=sse"; confflags="-b 64" - else mflags="$mflags -maltivec -mabi=altivec" + else mflags="$mflags -maltivec -mabi=altivec"; confflags="$confflags -t 0" if [ `machine|sed -e 's,ppc,,' -e 's,\([0-9]\).*,\1,'` != 9 ] then confflags='-Si cputhrchk 0 -D c -DATL_AVgcc -b 32' fi I see the same failure you do, but also noticed that it is preceded by another failure... touch slib.grd cd /sw/src/fink.build/atlas-3.9.76-5/SHAR_bld/interfaces/blas/C/src/ ; make ptlib make dptlvl3.grd ... /sw/src/fink.build/atlas-3.9.76-5/ATLAS/ar2 r cblas_dptgemm.o cblas_dptsymm.o cblas_dptsyr2k.o cblas_dptsyrk.o cblas_dpttrmm.o cblas_dpttrsm.o cblas_xerbla.o cblas_errprn.o ar: cblas_dptgemm.o: Inappropriate file type or format ranlib ranlib: no archives specified Looking at the offending file. I see... file cblas_dptgemm.o cblas_dptgemm.o: current ar archive random library So it appears to me that the Makefiles are messing up the call to ar by not passing it a static lib name on $(PTCBLASlib). Jack ps Perhaps the smartest thing would be to install current MacPorts on ppc darwin9 and make sure that their atlas packaging for 3.9.76 doesn't have the same problem. Frankly I don't believe ppc gets all that much testing these days (especially for a more obscure package like atlas). > > -- > Alexander Hansen, Ph.D. > Fink User Liaison > http://finkakh.wordpress.com/2012/02/21/got-job/ |
From: Alexander H. <ale...@gm...> - 2012-06-06 16:59:40
|
On 6/6/12 9:41 AM, Alexander Hansen wrote: > On 6/6/12 9:37 AM, jfm wrote: >> >> On Jun 6, 2012, at 5:20 PM, Alexander Hansen wrote: >> >>> On 6/5/12 11:15 AM, Alexander Hansen wrote: >>>> On 6/5/12 11:03 AM, Jack Howarth wrote: >>>>> Alexander, >>>>> Do you have a previous build of an earlier altas installed? A google on ATL_FreeAtomicCount undefined >>>>> produced... >>>>> >>>>> http://trac.sagemath.org/sage_trac/ticket/12349 >>>>> >>>>> Jack >>>> >>>> >>>> Yes, since the new packaging didn't explicitly forbid it in any way. >>>> >>> >>> I don't think a previous atlas is too likely to be causing the problem >>> since I was able to update from 3.9.11 to 3.9.76 on 10.5/i386. >> Right. If you look at your link command in this thread, this looks impossible. >> Sounds much more likely that those .o files were for some reason not made. >> Trivial to look into your libatlas.a to see if they are there... (But I can't look >> into your builddir.) >> It may be useful to send a bug report upstream, since upstream's G4 is dead, >> so no more testing on G4 ... (cf. http://www.cs.utsa.edu/~whaley/ATL310/) >>> $ find /sw/src/fink.build/atlas-3.9.76-4/ -name "*Atomic*.o" /sw/src/fink.build/atlas-3.9.76-4/SHAR_bld/lib/tmp/ATL_DecGlobalAtomicCount.o /sw/src/fink.build/atlas-3.9.76-4/SHAR_bld/lib/tmp/ATL_FreeGlobalAtomicCount.o /sw/src/fink.build/atlas-3.9.76-4/SHAR_bld/lib/tmp/ATL_GetAtomicCount.o /sw/src/fink.build/atlas-3.9.76-4/SHAR_bld/lib/tmp/ATL_GetGlobalAtomicCount.o /sw/src/fink.build/atlas-3.9.76-4/SHAR_bld/lib/tmp/ATL_ResetGlobalAtomicCount.o /sw/src/fink.build/atlas-3.9.76-4/SHAR_bld/lib/tmp/ATL_SetGlobalAtomicCount.o /sw/src/fink.build/atlas-3.9.76-4/SHAR_bld/src/threads/ATL_DecGlobalAtomicCount.o /sw/src/fink.build/atlas-3.9.76-4/SHAR_bld/src/threads/ATL_FreeGlobalAtomicCount.o /sw/src/fink.build/atlas-3.9.76-4/SHAR_bld/src/threads/ATL_GetAtomicCount.o /sw/src/fink.build/atlas-3.9.76-4/SHAR_bld/src/threads/ATL_GetGlobalAtomicCount.o /sw/src/fink.build/atlas-3.9.76-4/SHAR_bld/src/threads/ATL_ResetGlobalAtomicCount.o /sw/src/fink.build/atlas-3.9.76-4/SHAR_bld/src/threads/ATL_SetGlobalAtomicCount.o /sw/src/fink.build/atlas-3.9.76-4/STAT_bld/src/threads/ATL_DecGlobalAtomicCount.o /sw/src/fink.build/atlas-3.9.76-4/STAT_bld/src/threads/ATL_FreeGlobalAtomicCount.o /sw/src/fink.build/atlas-3.9.76-4/STAT_bld/src/threads/ATL_GetAtomicCount.o /sw/src/fink.build/atlas-3.9.76-4/STAT_bld/src/threads/ATL_GetGlobalAtomicCount.o /sw/src/fink.build/atlas-3.9.76-4/STAT_bld/src/threads/ATL_ResetGlobalAtomicCount.o /sw/src/fink.build/atlas-3.9.76-4/STAT_bld/src/threads/ATL_SetGlobalAtomicCount.o So I'm not seeing FreeAtomicCount, ResetAtomicCount, DecAtomicCount, or SetAtomicCount. Indeed, these appear never to get built, and there was not even an error indicating that an _attempt_ was made and failed: $ grep FreeAtomicCount fink-build-log_atlas_3.9.76-4_2012.06.04-11.12.57 ATLAS/src/threads/ATL_FreeAtomicCount_arch.c ATLAS/src/threads/ATL_FreeAtomicCount_mut.c "_ATL_FreeAtomicCount", referenced from: $ grep ResetAtomicCount fink-build-log_atlas_3.9.76-4_2012.06.04-11.12.57 ATLAS/src/threads/ATL_ResetAtomicCount_mut.c ATLAS/src/threads/ATL_ResetAtomicCount_amd64.S ATLAS/src/threads/ATL_ResetAtomicCount_ia32.S ATLAS/src/threads/ATL_ResetAtomicCount_mips.S ATLAS/src/threads/ATL_ResetAtomicCount_ppc.S ATLAS/src/threads/ATL_ResetAtomicCount_sparc.S "_ATL_ResetAtomicCount", referenced from: $ grep DecAtomicCount fink-build-log_atlas_3.9.76-4_2012.06.04-11.12.57 ATLAS/src/threads/ATL_DecAtomicCount_mut.c ATLAS/src/threads/ATL_DecAtomicCount_amd64.S ATLAS/src/threads/ATL_DecAtomicCount_ia32.S ATLAS/src/threads/ATL_DecAtomicCount_mips.S ATLAS/src/threads/ATL_DecAtomicCount_ppc.S ATLAS/src/threads/ATL_DecAtomicCount_sparc.S "_ATL_DecAtomicCount", referenced from: $ grep SetAtomicCount fink-build-log_atlas_3.9.76-4_2012.06.04-11.12.57 ATLAS/src/threads/ATL_SetAtomicCount_arch.c ATLAS/src/threads/ATL_SetAtomicCount_mut.c "_ATL_SetAtomicCount", referenced from: -- Alexander Hansen, Ph.D. Fink User Liaison http://finkakh.wordpress.com/2012/02/21/got-job/ |
From: jfm <jf...@co...> - 2012-06-06 17:03:54
|
On Jun 6, 2012, at 6:59 PM, Alexander Hansen wrote: > On 6/6/12 9:41 AM, Alexander Hansen wrote: >> On 6/6/12 9:37 AM, jfm wrote: >>> >>> On Jun 6, 2012, at 5:20 PM, Alexander Hansen wrote: >>> >>>> On 6/5/12 11:15 AM, Alexander Hansen wrote: >>>>> On 6/5/12 11:03 AM, Jack Howarth wrote: >>>>>> Alexander, >>>>>> Do you have a previous build of an earlier altas installed? A google on ATL_FreeAtomicCount undefined >>>>>> produced... >>>>>> >>>>>> http://trac.sagemath.org/sage_trac/ticket/12349 >>>>>> >>>>>> Jack >>>>> >>>>> >>>>> Yes, since the new packaging didn't explicitly forbid it in any way. >>>>> >>>> >>>> I don't think a previous atlas is too likely to be causing the problem >>>> since I was able to update from 3.9.11 to 3.9.76 on 10.5/i386. >>> Right. If you look at your link command in this thread, this looks impossible. >>> Sounds much more likely that those .o files were for some reason not made. >>> Trivial to look into your libatlas.a to see if they are there... (But I can't look >>> into your builddir.) >>> It may be useful to send a bug report upstream, since upstream's G4 is dead, >>> so no more testing on G4 ... (cf. http://www.cs.utsa.edu/~whaley/ATL310/) >>>> > > > $ find /sw/src/fink.build/atlas-3.9.76-4/ -name "*Atomic*.o" > /sw/src/fink.build/atlas-3.9.76-4/SHAR_bld/lib/tmp/ATL_DecGlobalAtomicCount.o > /sw/src/fink.build/atlas-3.9.76-4/SHAR_bld/lib/tmp/ATL_FreeGlobalAtomicCount.o > /sw/src/fink.build/atlas-3.9.76-4/SHAR_bld/lib/tmp/ATL_GetAtomicCount.o > /sw/src/fink.build/atlas-3.9.76-4/SHAR_bld/lib/tmp/ATL_GetGlobalAtomicCount.o > /sw/src/fink.build/atlas-3.9.76-4/SHAR_bld/lib/tmp/ATL_ResetGlobalAtomicCount.o > /sw/src/fink.build/atlas-3.9.76-4/SHAR_bld/lib/tmp/ATL_SetGlobalAtomicCount.o > /sw/src/fink.build/atlas-3.9.76-4/SHAR_bld/src/threads/ATL_DecGlobalAtomicCount.o > /sw/src/fink.build/atlas-3.9.76-4/SHAR_bld/src/threads/ATL_FreeGlobalAtomicCount.o > /sw/src/fink.build/atlas-3.9.76-4/SHAR_bld/src/threads/ATL_GetAtomicCount.o > /sw/src/fink.build/atlas-3.9.76-4/SHAR_bld/src/threads/ATL_GetGlobalAtomicCount.o > /sw/src/fink.build/atlas-3.9.76-4/SHAR_bld/src/threads/ATL_ResetGlobalAtomicCount.o > /sw/src/fink.build/atlas-3.9.76-4/SHAR_bld/src/threads/ATL_SetGlobalAtomicCount.o > /sw/src/fink.build/atlas-3.9.76-4/STAT_bld/src/threads/ATL_DecGlobalAtomicCount.o > /sw/src/fink.build/atlas-3.9.76-4/STAT_bld/src/threads/ATL_FreeGlobalAtomicCount.o > /sw/src/fink.build/atlas-3.9.76-4/STAT_bld/src/threads/ATL_GetAtomicCount.o > /sw/src/fink.build/atlas-3.9.76-4/STAT_bld/src/threads/ATL_GetGlobalAtomicCount.o > /sw/src/fink.build/atlas-3.9.76-4/STAT_bld/src/threads/ATL_ResetGlobalAtomicCount.o > /sw/src/fink.build/atlas-3.9.76-4/STAT_bld/src/threads/ATL_SetGlobalAtomicCount.o > > So I'm not seeing FreeAtomicCount, ResetAtomicCount, DecAtomicCount, or > SetAtomicCount. Indeed, these appear never to get built, and there was > not even an error indicating that an _attempt_ was made and failed: > > $ grep FreeAtomicCount fink-build-log_atlas_3.9.76-4_2012.06.04-11.12.57 > ATLAS/src/threads/ATL_FreeAtomicCount_arch.c > ATLAS/src/threads/ATL_FreeAtomicCount_mut.c > "_ATL_FreeAtomicCount", referenced from: > > $ grep ResetAtomicCount fink-build-log_atlas_3.9.76-4_2012.06.04-11.12.57 > ATLAS/src/threads/ATL_ResetAtomicCount_mut.c > ATLAS/src/threads/ATL_ResetAtomicCount_amd64.S > ATLAS/src/threads/ATL_ResetAtomicCount_ia32.S > ATLAS/src/threads/ATL_ResetAtomicCount_mips.S > ATLAS/src/threads/ATL_ResetAtomicCount_ppc.S > ATLAS/src/threads/ATL_ResetAtomicCount_sparc.S > "_ATL_ResetAtomicCount", referenced from: > > $ grep DecAtomicCount fink-build-log_atlas_3.9.76-4_2012.06.04-11.12.57 > ATLAS/src/threads/ATL_DecAtomicCount_mut.c > ATLAS/src/threads/ATL_DecAtomicCount_amd64.S > ATLAS/src/threads/ATL_DecAtomicCount_ia32.S > ATLAS/src/threads/ATL_DecAtomicCount_mips.S > ATLAS/src/threads/ATL_DecAtomicCount_ppc.S > ATLAS/src/threads/ATL_DecAtomicCount_sparc.S > "_ATL_DecAtomicCount", referenced from: > > $ grep SetAtomicCount fink-build-log_atlas_3.9.76-4_2012.06.04-11.12.57 > ATLAS/src/threads/ATL_SetAtomicCount_arch.c > ATLAS/src/threads/ATL_SetAtomicCount_mut.c > "_ATL_SetAtomicCount", referenced from: Great ! So I think this you can send upstream as bug-report... Possibly Clint sees immediately the cause of the problem .. JF |
From: Alexander H. <ale...@gm...> - 2012-06-06 17:46:57
|
On 6/6/12 9:55 AM, Jack Howarth wrote: > On Wed, Jun 06, 2012 at 09:41:32AM -0700, Alexander Hansen wrote: >> On 6/6/12 9:37 AM, jfm wrote: >>> >>> On Jun 6, 2012, at 5:20 PM, Alexander Hansen wrote: >>> >>>> On 6/5/12 11:15 AM, Alexander Hansen wrote: >>>>> On 6/5/12 11:03 AM, Jack Howarth wrote: >>>>>> Alexander, >>>>>> Do you have a previous build of an earlier altas installed? A google on ATL_FreeAtomicCount undefined >>>>>> produced... >>>>>> >>>>>> http://trac.sagemath.org/sage_trac/ticket/12349 >>>>>> >>>>>> Jack >>>>> >>>>> >>>>> Yes, since the new packaging didn't explicitly forbid it in any way. >>>>> >>>> >>>> I don't think a previous atlas is too likely to be causing the problem >>>> since I was able to update from 3.9.11 to 3.9.76 on 10.5/i386. >>> Right. If you look at your link command in this thread, this looks impossible. >>> Sounds much more likely that those .o files were for some reason not made. >>> Trivial to look into your libatlas.a to see if they are there... (But I can't look >>> into your builddir.) >>> It may be useful to send a bug report upstream, since upstream's G4 is dead, >>> so no more testing on G4 ... (cf. http://www.cs.utsa.edu/~whaley/ATL310/) >>>> >>>> I got the same failure again on PowerPC with the change that I made. >>> which change ? >>>> >> >> Sorry, I should have said. :-) >> >> It was to use "-Si archdef 0" in the ConfigureParams, since that's what >> David Fang was doing in his experimental tree for PowerPC builds. >> >>>> While I try what Jack suggested in IRC (adding -t0) to the mflags, >>> >>> what is this, and why should it help ?? >>> >>> JF >>> >> >> I think it turns off threading. He got it from the powerpc section of >> Macports' atlas Portfile. > > Alexander, > Testing the following change to the current atlas.info on 10.5 ppc darwin... > > --- /sw/fink/10.4/stable/main/finkinfo/sci/atlas.info 2012-06-05 15:16:34.000000000 -0400 > +++ atlas.info 2012-06-05 15:42:54.000000000 -0400 > @@ -1,7 +1,6 @@ > Package: atlas > Version: 3.9.76 > -Revision: 3 > -Architecture: i386, x86_64 > +Revision: 5 > Description: Portable optimal linear algebra software > DescDetail: << > The current version provides a complete BLAS and LAPACK API. > @@ -106,7 +105,7 @@ > then mflags="$mflags -m32 -mfpmath=sse" > else if [ "%m" = 'x86_64' ] > then mflags="$mflags -m64 -mfpmath=sse"; confflags="-b 64" > - else mflags="$mflags -maltivec -mabi=altivec" > + else mflags="$mflags -maltivec -mabi=altivec"; confflags="$confflags -t 0" > if [ `machine|sed -e 's,ppc,,' -e 's,\([0-9]\).*,\1,'` != 9 ] > then confflags='-Si cputhrchk 0 -D c -DATL_AVgcc -b 32' > fi > > I see the same failure you do, but also noticed that it is preceded by another failure... > > touch slib.grd > cd /sw/src/fink.build/atlas-3.9.76-5/SHAR_bld/interfaces/blas/C/src/ ; make ptlib > make dptlvl3.grd > ... > /sw/src/fink.build/atlas-3.9.76-5/ATLAS/ar2 r cblas_dptgemm.o cblas_dptsymm.o cblas_dptsyr2k.o cblas_dptsyrk.o cblas_dpttrmm.o cblas_dpttrsm.o cblas_xerbla.o cblas_errprn.o > ar: cblas_dptgemm.o: Inappropriate file type or format > ranlib > ranlib: no archives specified > > Looking at the offending file. I see... > > file cblas_dptgemm.o > cblas_dptgemm.o: current ar archive random library > > So it appears to me that the Makefiles are messing up the call to ar by not passing it > a static lib name on $(PTCBLASlib). > Jack > ps Perhaps the smartest thing would be to install current MacPorts on ppc darwin9 and > make sure that their atlas packaging for 3.9.76 doesn't have the same problem. Frankly > I don't believe ppc gets all that much testing these days (especially for a more obscure > package like atlas). > >> I can confirm seeing the same thing here. I'm generating a log from my fast machine (10.7/x86_64) for comparison purposes. -- Alexander Hansen, Ph.D. Fink User Liaison http://finkakh.wordpress.com/2012/02/21/got-job/ |
From: Jack H. <ho...@br...> - 2012-06-07 13:08:18
|
Alexander, The build of MacPorts' atlas 3.9.76 completed without error on ppc darwin9 in only 10 hours. They do only build the static libs. On the other hand, I notice that the INSTALL.txt in atlas 3.9.76 has a section... ********************** BUILDING DYNAMIC/SHARED LIBRARIES ********************** ATLAS natively builds to a static library (i.e. libs that usually end in ".a" under unix and ".lib" under windows). ATLAS always builds such a library, but it can also optionally be requested to build a dynamic/shared library (typically ending in .so for unix or .dll windows). In order to do so, you must tell ATLAS up front to compile with the proper flags (the same is true when building netlib's LAPACK, see the LAPACK note below). Assuming you are using the gnu C and Fortran compilers, you can add the following commands to your configure command: -Fa alg -fPIC to force ATLAS to be built using position independent code (required for a dynamic lib). If you use non-gnu compilers, you'll need to use -Fa to pass the correct flag(s) to append to force position independent code for each compiler (don't forget the gcc compiler used in the index files). NOTE: Since gcc uses one less int register when compiling with this flag, this could potentially impact performance of the architectural defaults, but we have not seen it so far. After you build is complete, you can cd to the OBJdir/lib directory, and ask ATLAS to build the .so you want. If you want all libraries, including the Fortran77 routines, the target choices are : shared : Create shared versions of ATLAS's sequential libs ptshared : Create shared versions of ATLAS's threaded libs If you want only the C routines (eg. you don't have a fortran compiler): cshared : Create shared versions of ATLAS's sequential libs cptshared : Create shared versions of ATLAS's threaded libs ...and I don't see any place in atlas.info where we use 'make shared' or 'make ptshared'. Also note that the makes/Make.lib file has a section... # ======================================================================= # The following commands are to build dynamib libraries on OS X (in BETA) # ======================================================================= dylib : rm -rf $(tmpd) ; mkdir $(tmpd) cd $(tmpd) ; ar x ../liblapack.a cd $(tmpd) ; ar x ../libf77blas.a cd $(tmpd) ; ar x ../libcblas.a cd $(tmpd) ; ar x ../libatlas.a cd $(tmpd) ; $(LIBTOOL) -dynamic -o ../libsatlas.dylib \ -install_name $(LIBINSTdir)/libsatlas.dylib -current_version $(VER) \ *.o $(LIBS) $(F77SYSLIB) $(F77SYSLIB) rm -rf $(tmpd) ptdylib : rm -rf $(tmpd) ; mkdir $(tmpd) cd $(tmpd) ; ar x ../libptlapack.a cd $(tmpd) ; ar x ../libptf77blas.a cd $(tmpd) ; ar x ../libptcblas.a cd $(tmpd) ; ar x ../libatlas.a cd $(tmpd) ; $(LIBTOOL) -dynamic -o ../libtatlas.dylib \ -install_name $(LIBINSTdir)/libtatlas.dylib -current_version $(VER) \ *.o $(LIBS) $(F77SYSLIB) rm -rf $(tmpd) cdylib : libclapack.a rm -rf $(tmpd) ; mkdir $(tmpd) cd $(tmpd) ; ar x ../libclapack.a cd $(tmpd) ; ar x ../libcblas.a cd $(tmpd) ; ar x ../libatlas.a cd $(tmpd) ; $(LIBTOOL) -dynamic -o ../libsatlas.dylib \ -install_name $(LIBINSTdir)/libsatlas.dylib -current_version $(VER) \ *.o $(LIBS) rm -rf $(tmpd) ptcdylib : libptclapack.a rm -rf $(tmpd) ; mkdir $(tmpd) cd $(tmpd) ; ar x ../libptclapack.a cd $(tmpd) ; ar x ../libptcblas.a cd $(tmpd) ; ar x ../libatlas.a cd $(tmpd) ; $(LIBTOOL) -dynamic -o ../libtatlas.dylib \ -install_name $(LIBINSTdir)/libtatlas.dylib -current_version $(VER) \ *.o $(LIBS) rm -rf $(tmpd) libclapack.dylib : libcblas.dylib libatlas.dylib liblapack.a rm -rf $(tmpd) ; mkdir $(tmpd) cd $(tmpd) ; ar x ../liblapack.a rm -f $(tmpd)/*C2F $(tmpd)/*f77wrap* cd $(tmpd) ; $(LIBTOOL) -dynamic -o ../libclapack.dylib \ -install_name $(LIBINSTdir)/libclapack.dylib \ -current_version $(VER) \ *.o ../libcblas.dylib ../libatlas.dylib -lgcc_s.1 $(LIBS) rm -rf $(tmpd) xtst_lp: $(DYNlibs) $(ICC) $(CDEFS) -o $@ $(mySRCdir)/qr.c $(DYNlibs) -Wl,--rpath ./ xtst : $(DYNlibs) $(ICC) $(CDEFS) -o $@ $(mySRCdir)/test_dynlink.c $(DYNlibs) \ -Wl,--rpath ./ xtry_lp: $(ICC) $(CDEFS) -o $@ $(mySRCdir)/qr.c libsatlas.so -Wl,--rpath ./ xtry_lp_pt: $(ICC) $(CDEFS) -o $@ $(mySRCdir)/qr.c libtatlas.so -Wl,--rpath ./ xtry : $(ICC) $(CDEFS) -o $@ $(mySRCdir)/test_dynlink.c libsatlas.so \ -Wl,--rpath ./ xtry_pt : $(ICC) $(CDEFS) -o $@ $(mySRCdir)/test_dynlink.c libtatlas.so \ -Wl,--rpath ./ so perhaps we would have better luck if atlas.info used 'make dylib' and friends rather than manually crafting the shared libs. Jack |
From: Jack H. <ho...@br...> - 2012-06-08 14:52:10
|
On Wed, Jun 06, 2012 at 10:46:38AM -0700, Alexander Hansen wrote: > On 6/6/12 9:55 AM, Jack Howarth wrote: > > On Wed, Jun 06, 2012 at 09:41:32AM -0700, Alexander Hansen wrote: > >> On 6/6/12 9:37 AM, jfm wrote: > >>> > >>> On Jun 6, 2012, at 5:20 PM, Alexander Hansen wrote: > >>> > >>>> On 6/5/12 11:15 AM, Alexander Hansen wrote: > >>>>> On 6/5/12 11:03 AM, Jack Howarth wrote: > >>>>>> Alexander, > >>>>>> Do you have a previous build of an earlier altas installed? A google on ATL_FreeAtomicCount undefined > >>>>>> produced... > >>>>>> > >>>>>> http://trac.sagemath.org/sage_trac/ticket/12349 > >>>>>> > >>>>>> Jack > >>>>> > >>>>> > >>>>> Yes, since the new packaging didn't explicitly forbid it in any way. > >>>>> > >>>> > >>>> I don't think a previous atlas is too likely to be causing the problem > >>>> since I was able to update from 3.9.11 to 3.9.76 on 10.5/i386. > >>> Right. If you look at your link command in this thread, this looks impossible. > >>> Sounds much more likely that those .o files were for some reason not made. > >>> Trivial to look into your libatlas.a to see if they are there... (But I can't look > >>> into your builddir.) > >>> It may be useful to send a bug report upstream, since upstream's G4 is dead, > >>> so no more testing on G4 ... (cf. http://www.cs.utsa.edu/~whaley/ATL310/) > >>>> > >>>> I got the same failure again on PowerPC with the change that I made. > >>> which change ? > >>>> > >> > >> Sorry, I should have said. :-) > >> > >> It was to use "-Si archdef 0" in the ConfigureParams, since that's what > >> David Fang was doing in his experimental tree for PowerPC builds. Why exactly are we using "-Si archdef 0" again? The reason I ask is that I noticed that for both MacPorts and fink, it appears that the code in CONFIG/src ends up setting the arch to PPC432 or PPC532 whereas the Makefiles end up trying to untar PPC432.tgz or PPC532.tgz when recent atlas releases only has PPCG432AltiVec.tgz and PPCG532AltiVec.tgz. It make not be related to the immediate failure we are seeing but it doesn't seem like the behavior intended by upstream. We probably should start filing bug reports with upstream on these issues if we really intend to keep supporting ppc darwin9. Jack > >> > >>>> While I try what Jack suggested in IRC (adding -t0) to the mflags, > >>> > >>> what is this, and why should it help ?? > >>> > >>> JF > >>> > >> > >> I think it turns off threading. He got it from the powerpc section of > >> Macports' atlas Portfile. > > > > Alexander, > > Testing the following change to the current atlas.info on 10.5 ppc darwin... > > > > --- /sw/fink/10.4/stable/main/finkinfo/sci/atlas.info 2012-06-05 15:16:34.000000000 -0400 > > +++ atlas.info 2012-06-05 15:42:54.000000000 -0400 > > @@ -1,7 +1,6 @@ > > Package: atlas > > Version: 3.9.76 > > -Revision: 3 > > -Architecture: i386, x86_64 > > +Revision: 5 > > Description: Portable optimal linear algebra software > > DescDetail: << > > The current version provides a complete BLAS and LAPACK API. > > @@ -106,7 +105,7 @@ > > then mflags="$mflags -m32 -mfpmath=sse" > > else if [ "%m" = 'x86_64' ] > > then mflags="$mflags -m64 -mfpmath=sse"; confflags="-b 64" > > - else mflags="$mflags -maltivec -mabi=altivec" > > + else mflags="$mflags -maltivec -mabi=altivec"; confflags="$confflags -t 0" > > if [ `machine|sed -e 's,ppc,,' -e 's,\([0-9]\).*,\1,'` != 9 ] > > then confflags='-Si cputhrchk 0 -D c -DATL_AVgcc -b 32' > > fi > > > > I see the same failure you do, but also noticed that it is preceded by another failure... > > > > touch slib.grd > > cd /sw/src/fink.build/atlas-3.9.76-5/SHAR_bld/interfaces/blas/C/src/ ; make ptlib > > make dptlvl3.grd > > ... > > /sw/src/fink.build/atlas-3.9.76-5/ATLAS/ar2 r cblas_dptgemm.o cblas_dptsymm.o cblas_dptsyr2k.o cblas_dptsyrk.o cblas_dpttrmm.o cblas_dpttrsm.o cblas_xerbla.o cblas_errprn.o > > ar: cblas_dptgemm.o: Inappropriate file type or format > > ranlib > > ranlib: no archives specified > > > > Looking at the offending file. I see... > > > > file cblas_dptgemm.o > > cblas_dptgemm.o: current ar archive random library > > > > So it appears to me that the Makefiles are messing up the call to ar by not passing it > > a static lib name on $(PTCBLASlib). > > Jack > > ps Perhaps the smartest thing would be to install current MacPorts on ppc darwin9 and > > make sure that their atlas packaging for 3.9.76 doesn't have the same problem. Frankly > > I don't believe ppc gets all that much testing these days (especially for a more obscure > > package like atlas). > > > >> > > I can confirm seeing the same thing here. I'm generating a log from my > fast machine (10.7/x86_64) for comparison purposes. > > > -- > Alexander Hansen, Ph.D. > Fink User Liaison > http://finkakh.wordpress.com/2012/02/21/got-job/ |
From: jfm <jf...@co...> - 2012-06-08 16:02:54
|
On Jun 8, 2012, at 4:51 PM, Jack Howarth wrote: > Why exactly are we using "-Si archdef 0" again? The reason I ask is that I noticed > that for both MacPorts and fink, it appears that the code in CONFIG/src ends up > setting the arch to PPC432 or PPC532 whereas the Makefiles end up trying to untar > PPC432.tgz or PPC532.tgz when recent atlas releases only has PPCG432AltiVec.tgz > and PPCG532AltiVec.tgz. It make not be related to the immediate failure we are seeing > but it doesn't seem like the behavior intended by upstream. We probably should start > filing bug reports with upstream on these issues if we really intend to keep supporting > ppc darwin9. It was at all times in the exp version in my exp tree, for 2 reasons : 1) the code used to find correct archdefs has to be debugged too in new versions. 2) in new ("unstable" like 3.9...) versions, archdefs are not even available for quite some time. That version was copied (not by me ...) to the distribution. You're quite right that it is high time to send those bug-reports upstream, if none of us is willing to look himself into the cause ... (Workarounds for your above-mentioned problem would be easy : either "-Si archdef 0", or forcing the use of PPCG[45]32AltiVec.tgz _ say with a -A flag (but there is already special code (due to Dominique Dhumieres) in the confflags for G4's, so the whole thing would need rethinking..). But please file bug-reports upstream, so we get real corrections ! JFm |