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/
------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
Fink-devel mailing list
Fink-devel@lists.sourceforge.net
List archive:
http://news.gmane.org/gmane.os.apple.fink.devel
Subscription management:
https://lists.sourceforge.net/lists/listinfo/fink-devel
