William said the other day he was not aware of any fake gcc's. Well numpy has a
really dumb one, which looks like someone tried to work around 64-bit issues at
some time in the past.
drkir...@hawk:~/sage-4.4.2/spkg/standard/numpy-1.3.0.p3$ cat gcc_fake
#!/bin/bash
/usr/bin/gcc -m64 $@
now on my machine, /usr/bin/gcc is only version 3.4.3
drkir...@hawk:~/sage-4.4.2/spkg/standard/numpy-1.3.0.p3$ /usr/bin/gcc -v
Reading specs from /usr/sfw/lib/gcc/i386-pc-solaris2.11/3.4.3/specs
Configured with: /builds2/sfwnv-gate/usr/src/cmd/gcc/gcc-3.4.3/configure
--prefix=/usr/sfw --with-as=/usr/sfw/bin/gas --with-gnu-as
--with-ld=/usr/ccs/bin/ld --without-gnu-ld --enable-languages=c,c++,f77,objc
--enable-shared
Thread model: posix
gcc version 3.4.3 (csl-sol210-3_4-20050802)
I can't find any trac ticket which references gcc_fake, and there is no record
of it in SPKG.txt, but someone had the great idea of hard-coding the path to gcc
like that.
Tracking down build problems is very difficult when there are fake gcc's and
fake fortrans. I wish Sage could build without needing to resorting to such tricks.
Dave
--
To post to this group, send an email to [email protected]
To unsubscribe from this group, send an email to
[email protected]
For more options, visit this group at http://groups.google.com/group/sage-devel
URL: http://www.sagemath.org
