Another Solaris NTL problem

[Dr. David Kirkby]

I set up a Sun Ultra 60 for testing of sage and have mailed a couple
of people passwords. I just checked this, and found another issue with
NTL on the Ultra 60 which I did not notice on the Blade 2000.


It appears to fail with:

"make: Fatal error in reader: makefile, line 522: Macro assignment on
dependency line"

see below.

This happens with both /usr/ccs/bin/make and gnu make. Not sure how
this differrs much from the other Sun. As far as I know, they have the
same compilers and make programs!





x ntl-5.4.2.p3/src/src/RemoveProg, 51 bytes, 1 tape blocks
x ntl-5.4.2.p3/src/src/cfile, 15983 bytes, 32 tape blocks
x ntl-5.4.2.p3/src/src/CharPolyTest.c, 213 bytes, 1 tape blocks
x ntl-5.4.2.p3/src/src/pair_GF2EX_long.c, 385 bytes, 1 tape blocks
x ntl-5.4.2.p3/src/src/DispSettings.c, 2197 bytes, 5 tape blocks
x ntl-5.4.2.p3/src/src/pair_lzz_pX_long.c, 386 bytes, 1 tape blocks
Finished extraction
****************************************************
Host system
uname -a:
SunOS main-webserver 5.10 Generic_120011-14 sun4u sparc SUNW,Ultra-60
****************************************************
****************************************************
GCC Version
gcc -v
Reading specs from /opt/csw/gcc4/lib/gcc/sparc-sun-solaris2.8/4.0.2/
specs
Target: sparc-sun-solaris2.8
Configured with: ../sources/gcc-4.0.2/configure --prefix=/opt/csw/gcc4
--with-local-prefix=/opt/csw --without-gnu-as --with-as=/usr/ccs/bin/
as --without-gnu-ld --with-ld=/usr/ccs/bin/ld --enable-threads=posix --
enable-shared --enable-multilib --enable-nls --with-included-gettext --
with-libiconv-prefix=/opt/csw --with-x --enable-java-awt=xlib --with-
system-zlib --enable-languages=c,c++,f95,java,objc,ada
Thread model: posix
gcc version 4.0.2
****************************************************
writing makefile
writing ../include/NTL/config.h
Building and install NTL
make: Fatal error in reader: makefile, line 522: Macro assignment on
dependency line
Current working directory /export/home0/mabshoff/sage-3.0.2/spkg/build/
ntl-5.4.2.p3/src/src
Error creating ntl shared library.

real 0m0.307s
user 0m0.122s
sys 0m0.171s
sage: An error occurred while installing ntl-5.4.2.p3
Please email sage-devel http://groups.google.com/group/sage-devel
explaining the problem and send the relevant part of
of /export/home0/mabshoff/sage-3.0.2/install.log. Describe your
computer, operating system, etc.
If you want to try to fix the problem, yourself *don't* just cd to
/export/home0/mabshoff/sage-3.0.2/spkg/build/ntl-5.4.2.p3 and type
'make'.
Instead type "/export/home0/mabshoff/sage-3.0.2/sage -sh"
in order to set all environment variables correctly, then cd to
/export/home0/mabshoff/sage-3.0.2/spkg/build/ntl-5.4.2.p3
(When you are done debugging, you can type "exit" to leave the
subshell.)
*** Error code 1
make: Fatal error: Command failed for target `installed/ntl-5.4.2.p3'
Current working directory /export/home0/mabshoff/sage-3.0.2/spkg

real 26:55.5
user 17:33.1
sys 2:34.1

[Dr. David Kirkby]

> Please email sage-develhttp://groups.google.com/group/sage-devel

> explaining the problem and send the relevant part of
> of /export/home0/mabshoff/sage-3.0.2/install.log. Describe your
> computer, operating system, etc.
> If you want to try to fix the problem, yourself *don't* just cd to
> /export/home0/mabshoff/sage-3.0.2/spkg/build/ntl-5.4.2.p3 and type
> 'make'.
> Instead type "/export/home0/mabshoff/sage-3.0.2/sage -sh"
> in order to set all environment variables correctly, then cd to
> /export/home0/mabshoff/sage-3.0.2/spkg/build/ntl-5.4.2.p3
> (When you are done debugging, you can type "exit" to leave the
> subshell.)
> *** Error code 1
> make: Fatal error: Command failed for target `installed/ntl-5.4.2.p3'
> Current working directory /export/home0/mabshoff/sage-3.0.2/spkg
>
> real 26:55.5
> user 17:33.1
> sys 2:34.1

For what it is worth, this is line 522:

shobj: FPICFLAG = -fPIC

Perhaps I should have built it from scratch with gnu make. Anyway, I
hope I've found a few things that hopefully someone has some idea how
to fix!!!

Dave

[Francois]

On Jun 5, 1:37 pm, "Dr. David Kirkby" <david.kir...@onetel.net> wrote:
>
>
> For what it is worth, this is line 522:
>
> shobj: FPICFLAG = -fPIC
>
> Perhaps I should have built it from scratch with gnu make. Anyway, I
> hope I've found a few things that hopefully someone has some idea how
> to fix!!!
>

I fess up, that's one of my bits. I presume it is a GNU-ism but I am
not sure why it wouldn't work with gmake.

Francois

[Francois]

I guess it happens because the makefile is full of direct calls
to make rather than something like $MAKE. So even if you
started with gmake you will call make eventually which will
protest to GNU-ism. Add this to my TODO list:
Find a way of assigning a variable/macro inside a target
that is GNU independent. Feel free to educate me!

Francois

[mabshoff]

Well, we require gmake anyway for freetype since that specifically
requires gmake. gld should not be required, at least unless we call it
explicitly.

For gmake: call ${MAKE-make} instead of make when invoking a target
and as long as the makefile is being build with the right "make" it
will work. That is the fix I have for eclib in the wings.

Overall I do not care for sonames for libraries since we do not
provide a versioning interface anyway. Since Debian requires it [and
maybe other distributions] those should patch them into the makefile.
Add autohell to a whole new set of packages is not the answer since we
are turning a nuisance into a steaming pile of crap. I would much
rather use SCons or CMake.

As is no spkg will be updated without working with Sun's make [unless
gmake is required] and ld. It will take a little while to get the
existing kinks out of the system, but one of my Solaris boxen is set
up that way so I am happy to verify that personally ;)

> Francois

Cheers,

Michael

[Dr. David Kirkby]

On 5 Jun, 15:03, mabshoff <mabsh...@googlemail.com> wrote:

> Well, we require gmake anyway for freetype since that specifically
> requires gmake. gld should not be required, at least unless we call it
> explicitly.

The only way I can get things to at least work semi-well is to copy
gmake to $HOME/bin/make, then make sure $HOME/bin is the first thing
in the path. Then, no matter whether you call gmake or make, you
actually get gmake. It is not very elegant, but does work without
changing the scripts.

But it would be much more sensible to remove any references to 'make'
in the files, and instead use $MAKE.

On another topic, can you explain how I should attempt to build sage
if I make a change to a file? Let's say I make a change to the NTL
makefile

./spkg/build/ntl-5.4.2.p3/src/src/makefile

which is the simplist way to start the build process so it uses that
revised makefile? I thought you said this was documented somewhere,
but I can't find it. I'm still recreating a new .spkg file, which is
tedious and so does not encourage one to try to fix problems.

Dave

[mabshoff]

On Jun 5, 4:13 pm, "Dr. David Kirkby" <david.kir...@onetel.net> wrote:
> On 5 Jun, 15:03, mabshoff <mabsh...@googlemail.com> wrote:

Hi David,

> > Well, we require gmake anyway for freetype since that specifically
> > requires gmake. gld should not be required, at least unless we call it
> > explicitly.
>
> The only way I can get things to at least work semi-well is to copy
> gmake to $HOME/bin/make, then make sure $HOME/bin is the first thing
> in the path. Then, no matter whether you call gmake or make, you
> actually get gmake. It is not very elegant, but does work without
> changing the scripts.

Yep, I have thought about doing that automatically for gamke, gtar,
gas, ginstall and gld, i.e. link them into $SAGE_ROOT/local/bin
without the "g", but so far I don't think that is a good idea. Once I
switch to the Sun Forte compiler I plan to take /opt/sfw/bin out of
$PATH [on some Sun boxen it is /usr/sfw/bin for some reason, maybe
Sparc vs. x86/x86-64?]. At that point I plan to use Sun tools all the
way via /usr/bin/ccs or so.

> But it would be much more sensible to remove any references to 'make'
> in the files, and instead use $MAKE.
>
> On another topic, can you explain how I should attempt to build sage
> if I make a change to a file? Let's say I make a change to the NTL
> makefile
>
> ./spkg/build/ntl-5.4.2.p3/src/src/makefile
>
> which is the simplist way to start the build process so it uses that
> revised makefile? I thought you said this was documented somewhere,
> but I can't find it. I'm still recreating a new .spkg file, which is
> tedious and so does not encourage one to try to fix problems.

a) from $SAGE_ROOT source local/bin/sage-env
b) unpack the spkg or go into the build directory
c) edit files/make changes
d) run ./spkg-install
e) lather, rinse, repear

finally once the spkg is installed do a "touch spkg/installed/$FOO"
for $FOO.spkg

> Dave

Cheers,

Michael

[Francois]

On Jun 6, 2:03 am, mabshoff <mabsh...@googlemail.com> wrote:
> On Jun 5, 11:07 am, Francois <f.r.bis...@massey.ac.nz> wrote:
>
> > I guess it happens because the makefile is full of direct calls
> > to make rather than something like $MAKE. So even if you
> > started with gmake you will call make eventually which will
> > protest to GNU-ism. Add this to my TODO list:
> > Find a way of assigning a variable/macro inside a target
> > that is GNU independent. Feel free to educate me!
>
> Well, we require gmake anyway for freetype since that specifically
> requires gmake. gld should not be required, at least unless we call it
> explicitly.
>
> For gmake: call ${MAKE-make} instead of make when invoking a target
> and as long as the makefile is being build with the right "make" it
> will work. That is the fix I have for eclib in the wings.
>
> Overall I do not care for sonames for libraries since we do not
> provide a versioning interface anyway. Since Debian requires it [and
> maybe other distributions] those should patch them into the makefile.
> Add autohell to a whole new set of packages is not the answer since we
> are turning a nuisance into a steaming pile of crap. I would much
> rather use SCons or CMake.

I am fixing the make thing and it looks like we don't have very
much choice for ld. Everything that I tried to handle thing gracefully
failed.
autotools/scons/cmake is usually an interesting flame war bait but
I have no time researching that subject in depth. If it works it will
be
good enough for me.

>
> As is no spkg will be updated without working with Sun's make [unless
> gmake is required] and ld. It will take a little while to get the
> existing kinks out of the system, but one of my Solaris boxen is set
> up that way so I am happy to verify that personally ;)
>

OK.

Cheers,
Francois

[Francois]

I almost got it. It is make proof, I have a just a -fpic to clean.
I have one last error that I am not sure how to deal with:
g++ -I../include -I. -O2 -g -fPIC -fpic -o libntl.so FFT.o FacVec.o
GF2.o GF2E.o GF2EX.o GF2EXFactoring.o GF2X.o GF2X1.o GF2XFactoring.o
GF2XVec.o GetTime.o HNF.o ctools.o LLL.o LLL_FP.o LLL_QP.o LLL_RR.o
LLL_XD.o RR.o WordVector.o ZZ.o ZZVec.o ZZX.o ZZX1.o ZZXCharPoly.o
ZZXFactoring.o ZZ_p.o ZZ_pE.o ZZ_pEX.o ZZ_pEXFactoring.o ZZ_pX.o
ZZ_pX1.o ZZ_pXCharPoly.o ZZ_pXFactoring.o fileio.o lip.o lzz_p.o
lzz_pE.o lzz_pEX.o lzz_pEXFactoring.o lzz_pX.o lzz_pX1.o
lzz_pXCharPoly.o lzz_pXFactoring.o mat_GF2.o mat_GF2E.o mat_RR.o
mat_ZZ.o mat_ZZ_p.o mat_ZZ_pE.o mat_lzz_p.o mat_lzz_pE.o mat_poly_ZZ.o
mat_poly_ZZ_p.o mat_poly_lzz_p.o pair_GF2EX_long.o pair_GF2X_long.o
pair_ZZX_long.o pair_ZZ_pEX_long.o pair_ZZ_pX_long.o
pair_lzz_pEX_long.o pair_lzz_pX_long.o quad_float.o tools.o vec_GF2.o
vec_GF2E.o vec_GF2XVec.o vec_RR.o vec_ZZ.o vec_ZZVec.o vec_ZZ_p.o
vec_ZZ_pE.o vec_double.o vec_long.o vec_lzz_p.o vec_lzz_pE.o
vec_quad_float.o vec_vec_GF2.o vec_vec_GF2E.o vec_vec_RR.o
vec_vec_ZZ.o vec_vec_ZZ_p.o vec_vec_ZZ_pE.o vec_vec_long.o
vec_vec_lzz_p.o vec_vec_lzz_pE.o vec_xdouble.o xdouble.o G_LLL_FP.o
G_LLL_QP.o G_LLL_XD.o G_LLL_RR.o vec_ulong.o vec_vec_ulong.o -L/export/
home0/francois/sage-3.0.2/local/lib -lgmp
Undefined first referenced
symbol in file
main /opt/csw/gcc4/lib/gcc/sparc-sun-
solaris2.8/4.0.2/crt1.o
ld: fatal: Symbol referencing errors. No output written to libntl.so
collect2: ld returned 1 exit status
*** Error code 1
-------
Any idea Michael?

Cheers
Francois

[Francois]

Never mind! Silly me had removed "-shared" from the linking line.
I got past ntl. Next stop is eclib with this right at the beginning:

libcurvesntl.*: No such file or directory
libg0nntl.*: No such file or directory
libjcntl.*: No such file or directory
librankntl.*: No such file or directory
libmwrank.*: No such file or directory
Deleting old include directory
make: Fatal error in reader: Makefile, line 4: Badly formed macro
assignment
Current working directory /export/home0/francois/sage-3.0.2/spkg/build/
eclib-20080310.p1/src
Error building cremona

I will open a trac ticket with a patch for ntl when my 4month old
gives me time.

Francois

[Dr. David Kirkby]

On Jun 6, 1:04 am, Francois <f.r.bis...@massey.ac.nz> wrote:

> Never mind! Silly me had removed "-shared" from the linking line.
> I got past ntl.

Great, I copied your revised ntl package from your home directory (on
my Sun Ultra 60 called 'main-webserver') and it works ok, on both that
Sun and also on my Blade 2000 (kestrel) - no great surprise there, as
the two Suns are running very similar setups.

> Next stop is eclib with this right at the beginning:
>
> libcurvesntl.*: No such file or directory
> libg0nntl.*: No such file or directory
> libjcntl.*: No such file or directory
> librankntl.*: No such file or directory
> libmwrank.*: No such file or directory
> Deleting old include directory
> make: Fatal error in reader: Makefile, line 4: Badly formed macro
> assignment

This is odd. I noticed you get this failure on my Ultra 60, but I do
not get that failure, even on the same machine! Is it possible you
have messed something that calls eclib by mistake?

going a grep for eclib on the install.log on that Ultra 60 I see:

080310.p1/src/g0n'
make[2]: Leaving directory `/export/home/drkirkby/sage-3.0.2/spkg/
build/eclib-20080310.p1/src'
chown: eclib: Not owner
Successfully installed eclib-20080310.p1
/export/home/drkirkby/sage-3.0.2/spkg/build/eclib-20080310.p1
Finished installing eclib-20080310.p1.spkg

Clearly unless built as root, the call to chown is going to fail. Not
quite sure why chown is called, but I've not looked at the code.

[mabshoff]

On Jun 6, 7:45 am, "Dr. David Kirkby" <david.kir...@onetel.net> wrote:
> On Jun 6, 1:04 am, Francois <f.r.bis...@massey.ac.nz> wrote:
>
> > Never mind! Silly me had removed "-shared" from the linking line.
> > I got past ntl.
>
> Great, I copied your revised ntl package from your home directory (on
> my Sun Ultra 60 called 'main-webserver') and it works ok, on both that
> Sun and also on my Blade 2000 (kestrel) - no great surprise there, as
> the two Suns are running very similar setups.

Good.

> > Next stop is eclib with this right at the beginning:
>
> >   libcurvesntl.*: No such file or directory
> > libg0nntl.*: No such file or directory
> > libjcntl.*: No such file or directory
> > librankntl.*: No such file or directory
> > libmwrank.*: No such file or directory
> > Deleting old include directory
> > make: Fatal error in reader: Makefile, line 4: Badly formed macro
> > assignment

eclib needs gmake and I have a fix in the makefile, i.e. use ${MAKE-
make} in the main makefile to call the other makefiles and invoked
with gmake.

> This is odd. I noticed you get this failure on my Ultra 60, but I do
> not get that failure, even on the same machine! Is it possible you
> have messed something that calls eclib by mistake?

If you link gmake to make you would not see that problem.

> going a grep for eclib on the install.log on that Ultra 60 I see:
>
> 080310.p1/src/g0n'
> make[2]: Leaving directory `/export/home/drkirkby/sage-3.0.2/spkg/
> build/eclib-20080310.p1/src'
> chown: eclib: Not owner
> Successfully installed eclib-20080310.p1
> /export/home/drkirkby/sage-3.0.2/spkg/build/eclib-20080310.p1
> Finished installing eclib-20080310.p1.spkg
>
> Clearly unless built as root, the call to chown is going to fail. Not
> quite sure why chown is called, but I've not looked at the code.

It is a dumb bug that I thought I had fixed. For some reason my fix
either got reverted somehow [that happened at least one], but I just
fixed it in my spkg. So it will not happen in 3.0.3 anymore.

> > I will open a trac ticket with a patch for ntl when my 4month old
> > gives me time.
>
> > Francois

Cheers,

Michael

[Dr. David Kirkby]

On Jun 6, 7:00 am, mabshoff <mabsh...@googlemail.com> wrote:

> > Great, I copied your revised ntl package from your home directory (on
> > my Sun Ultra 60 called 'main-webserver') and it works ok, on both that
> > Sun and also on my Blade 2000 (kestrel) - no great surprise there, as
> > the two Suns are running very similar setups.
>
> Good.

The Solaris port does seem to be coming on, which is good. The ntl fix
from Francois seems to work on both my SPARCs. I do have another
problem, but that needs to be on another subject, not this one.

Hopefully, when you get Sage to the point it is working for a few
Solaris machines, I could ask on comp.unix.solaris if anyone else will
try to compile it. Chances are, someone on there will get a problem or
three, since no two people are likely to have exactly the same setup.

Dave

[mabshoff]

On Jun 6, 8:31 am, "Dr. David Kirkby" <david.kir...@onetel.net> wrote:
> On Jun 6, 7:00 am, mabshoff <mabsh...@googlemail.com> wrote:
>
> > > Great, I copied your revised ntl package from your home directory (on
> > > my Sun Ultra 60 called 'main-webserver') and it works ok, on both that
> > > Sun and also on my Blade 2000 (kestrel) - no great surprise there, as
> > > the two Suns are running very similar setups.
>
> > Good.
>
> The Solaris port does seem to be coming on, which is good. The ntl fix
> from Francois seems to work on both my SPARCs. I do have another
> problem, but that needs to be on another subject, not this one.

Thanks for testing ;)

> Hopefully, when you get Sage to the point it is working for a few
> Solaris machines, I could ask on comp.unix.solaris if anyone else will
> try to compile it. Chances are, someone on there will get a problem or
> three, since no two people are likely to have exactly the same setup.

Yes, that is definitely desired. The game plan is definitely to make
it work on the Solaris 10 boxen on SageNet since those nice people are
paying me to do the port. One problem with gcc and Solaris in general
is the lack of a working complex.h, so that needs to be resolved.
Another one is that on Solaris x86 [and x86-64] Sympow does not work
since it requires the FPU mode to be "low precision" and as it that
code does not work correctly. Since quaddouble works that should be
fixable.

> Dave

But the medium term plan is to switch to the Sun Forte compiler and I
have no intention to ever even put substantial time to make the 64 bit
port work with gcc. I have had to deal with too much crap with gcc in
64 bit mode on Solaris to even pursuit that, but patches and fixes are
obviously welcome. Since the Sun compiler is free as in beer I don't
think that is too much of a problem. Should Sun decide to do something
stupid and force people to pay for their compilers again we will
revisit gcc in 64 bit mode on Solaris again.

Cheers,

Michael

[Dr. David Kirkby]

On Jun 6, 7:44 am, mabshoff <mabsh...@googlemail.com> wrote:
> > The Solaris port does seem to be coming on, which is good. The ntl fix
> > from Francois seems to work on both my SPARCs. I do have another
> > problem, but that needs to be on another subject, not this one.
>
> Thanks for testing ;)

I should have added the problem I got was with 3.0.2, with twisted. I
think you have perhaps made some changes to that, so I'm in the
process of downloading sage-3.0.3.alpha1.tar. Unfortunately, I'm only
getting 50 KB/s, it will be another 15 minutes before I have the
tarball.

> But the medium term plan is to switch to the Sun Forte compiler and I
> have no intention to ever even put substantial time to make the 64 bit
> port work with gcc. I have had to deal with too much crap with gcc in
> 64 bit mode on Solaris to even pursuit that, but patches and fixes are
> obviously welcome. Since the Sun compiler is free as in beer I don't
> think that is too much of a problem. Should Sun decide to do something
> stupid and force people to pay for their compilers again we will
> revisit gcc in 64 bit mode on Solaris again.

Essentially the Sun compilers are faster than gcc, so changing for
that reason alone would be useful on code which is going to be CPU
intensive.

I can't see Sun trying to charge for their compilers again. I think
they would **** off too many people, including many of their own
employees. But who knows, they have made some odd decisions before
with how they changed the license conditions on Solaris.

* At one time Solaris was commerical only

* Then it became free for up to 8 CPUs. It did not inforce the 8-CPU
limit, but few people have machines with more than 8 CPUs.

* Then they called Solaris free, but in only if the machine was
capable of holding just one cpu, and furthermore the machine was
bought from a Sun authorised resller. This mean it was not free for
99% of users. In practice, since anyone could download it, you can
guess what people did.

* At one point they used to charge a nominal fee to download the x86,
but not SPARC version. I think they got fed up with a lot of
downloads, with people not bothering to install it. I can see some
logic in that.

* Then Solaris became free and open source.

So who knows? Depending on what way the wind is blowing, Sun will send
you a Solaris Express DVD and them pick up the postage, or you pay
for the postage. Their policy seems to change from week to week, with
no real logic to it.

Going back to Sage, I imagine the switch from gcc->Sun compilers is
going to present quite a few challenges, as the options are so
different. I believe there is a gcc interface to the Sun compilers so
it can be called with gcc options, but I think it is better to use the
right Forte options.

BTW, are there any other ports planned, like HP-UX? I have a HP-UX box
here, but it has not been switched on for many years. I also have
tru64 on a Dec Alpha, IRIX on an SGI Octane and AIX on a large IBM
server, but none of the machines have been on for years. About time I
got rid of them I guess! But I know from my efforts on ATLC
http://atlc.sourceforge.net/ that building software on multiple
platforms tends to find a lot of bugs, which don't show up on platform
A, but the bugs are there, ready to surface at some later date. ATLC
has been built on many platforms including a Sony Playstation and a
Cray supercomputer.

[mabshoff]

On Jun 6, 9:32 am, "Dr. David Kirkby" <david.kir...@onetel.net> wrote:
> On Jun 6, 7:44 am, mabshoff <mabsh...@googlemail.com> wrote:

Hi David,

> > > The Solaris port does seem to be coming on, which is good. The ntl fix
> > > from Francois seems to work on both my SPARCs. I do have another
> > > problem, but that needs to be on another subject, not this one.
>
> > Thanks for testing ;)
>
> I should have added the problem I got was with 3.0.2, with twisted. I
> think you have perhaps made some changes to that, so I'm in the
> process of downloading sage-3.0.3.alpha1.tar. Unfortunately, I'm only
> getting 50 KB/s, it will be another 15 minutes before I have the
> tarball.

That tarball issue with twisted has not been fixed yet since I have
not dropped the recompressed tar ball into alpha1 yet. The box I am
doing that is behind a firewall that blew up yesterday, but will
hopefully be operational again today.

> > But the medium term plan is to switch to the Sun Forte compiler and I
> > have no intention to ever even put substantial time to make the 64 bit
> > port work with gcc. I have had to deal with too much crap with gcc in
> > 64 bit mode on Solaris to even pursuit that, but patches and fixes are
> > obviously welcome. Since the Sun compiler is free as in beer I don't
> > think that is too much of a problem. Should Sun decide to do something
> > stupid and force people to pay for their compilers again we will
> > revisit gcc in 64 bit mode on Solaris again.
>
> Essentially the Sun compilers are faster than gcc, so changing for
> that reason alone would be useful on code which is going to be CPU
> intensive.

Well, I have seen those benchmark numbers but I will remain skeptical
until I ran Sage benchmarks myself. I once bought into the Intel C++
compiler creating 40% faster code than the gcc compiler [two, three
years back it was claimed that mysql compiled with Intel's C++
compiler was that much faster compated with the then current gcc
release] and for the code I was working with it turned out that gcc
was on average 2% faster than Intel's C++ compiler with CPU specific
tuning options and all bells & whistles like feedback optimization
turned on.

> I can't see Sun trying to charge for their compilers again. I think
> they would **** off too many people, including many of their own
> employees. But who knows, they have made some odd decisions before
> with how they changed the license conditions on Solaris.

Yes, Sun has done a lot of odd things in the last decade and their
somewhat uneasy hot and cold relationship with Linux has certainly not
made them too many friends in certain OS circles.

Charging for their development tools must be one of the dumbest moves
Sun ever did. It made people use gcc and so much software no longer
compiled with the Sun compiler any more. Since gcc could not produce
64 bit code on Solaris for a long time it also didn't make Sparc more
attractive either. Sparc's raw CPU power sucks anyway as is, but
fortunately Sun now figured out that making x86-64 boxen is good
business ;)

> * At one time Solaris was commerical only
>
> * Then it became free for up to 8 CPUs. It did not inforce the 8-CPU
> limit, but few people have machines with more than 8 CPUs.
>
> * Then they called Solaris free, but in only if the machine was
> capable of holding just one cpu, and furthermore the machine was
> bought from a Sun authorised resller. This mean it was not free for
> 99% of users. In practice, since anyone could download it, you can
> guess what people did.
>
> * At one point they used to charge a nominal fee to download the x86,
> but not SPARC version. I think they got fed up with a lot of
> downloads, with people not bothering to install it. I can see some
> logic in that.
>
> * Then Solaris became free and open source.

Well, you still have to register for the privilege to download
security fixes and that is annoying. I am sure that many people once
they get Solaris up and running will be turned off by that. Solaris
10's package selection mechanism is a joke [unfulfilled dependencies
are not resolved automatically on request, but you can try until you
can figure it out :)], but Indiana will hopefully fix that.

> So who knows? Depending on what way the wind is blowing, Sun will send
> you a Solaris Express DVD and them pick up  the postage, or you pay
> for the postage. Their policy seems to change from week to week, with
> no real logic to it.
>
> Going back to Sage, I imagine the switch from gcc->Sun compilers is
> going to present quite a few challenges, as the options are so
> different. I believe there is a gcc interface to the Sun compilers so
> it can be called with gcc options, but I think it is better to use the
> right Forte options.

I don't see much trouble in fixing the various flags, but then I have
worked with the Sun compilers for a while.

> BTW, are there any other ports planned, like HP-UX? I have a HP-UX box
> here, but it has not been switched on for many years. I also have
> tru64 on a Dec Alpha, IRIX on an SGI Octane and AIX on a large IBM
> server, but none of the machines have been on for years. About time I
> got rid of them I guess!

I have access to a multi CPU Dec Alpha with loads of RAM, but I don't
see any benefit from porting besides the potential bugs exposed.

For SageNet I have asked for HPUX/Itanium, PPC 64/AIX and PPC 64/
Linux. I am not sure if or when any of those will show up. Somebody
(Oskar) is currently porting Sage to IRIX for fun. In the end

* Windows x86, x86-64
* OSX x86, x86-64, ppc, ppc 64
* Solaris x86, x86-64, Sparc
* Linux x86, x86-64, Itanium

will cover the vast majority of available hardware out there.

> But I know from my efforts on ATLChttp://atlc.sourceforge.net/that building software on multiple

> platforms tends to find a lot of bugs, which don't show up on platform
> A, but the bugs are there, ready to surface at some later date. ATLC
> has been built on many platforms including a Sony Playstation and a
> Cray supercomputer.

I agree with you that this is a big benefit of porting to
"miscellaneous" platforms and the port to Linux/ppc for example has
turned up some interesting bugs that later popped up elsewhere (#1337
is a good example). That being said once we have the high priority
port targets working [basically the list above] I am more than
interested to port to something else provided you gave a shell account
for me to play with. But we do cover quite a large range of hardware
and finding targets that are viable is getting harder and harder. And
it doesn't look like we are running out of bugs to fix anytime soon ;)

Cheers,

Michael

[Francois]

On Jun 6, 6:44 pm, mabshoff <mabsh...@googlemail.com> wrote:
> On Jun 6, 8:31 am, "Dr. David Kirkby" <david.kir...@onetel.net> wrote:
>
> > On Jun 6, 7:00 am, mabshoff <mabsh...@googlemail.com> wrote:
>
> > > > Great, I copied your revised ntl package from your home directory (on
> > > > my Sun Ultra 60 called 'main-webserver') and it works ok, on both that
> > > > Sun and also on my Blade 2000 (kestrel) - no great surprise there, as
> > > > the two Suns are running very similar setups.
>
> > > Good.
>
> > The Solaris port does seem to be coming on, which is good. The ntl fix
> > from Francois seems to work on both my SPARCs. I do have another
> > problem, but that needs to be on another subject, not this one.
>
> Thanks for testing ;)
>

I am sure I don't need to tell you but I opened a ticket (#3375) with
a proper
mercurial patch (hg export tip > file.patch). I hope it is in the
right format for you.
I also gave enough clue so that it will not be a treasure hunt to know
what
I patched.

I may look at the other stuff we did with Tim that has been merged as
most of it will now have to be amended.

Francois

[Dr. David Kirkby]

On Jun 6, 9:05 am, mabshoff <mabsh...@googlemail.com> wrote:
> > * Then Solaris became free and open source.
>
> Well, you still have to register for the privilege to download
> security fixes and that is annoying. I am sure that many people once
> they get Solaris up and running will be turned off by that. Solaris
> 10's package selection mechanism is a joke [unfulfilled dependencies
> are not resolved automatically on request, but you can try until you
> can figure it out :)], but Indiana will hopefully fix that.

There is no big deal in registering. I don't have a problem with that.
There is no charge for it.

> > BTW, are there any other ports planned, like HP-UX? I have a HP-UX box
> > here, but it has not been switched on for many years. I also have
> > tru64 on a Dec Alpha, IRIX on an SGI Octane and AIX on a large IBM
> > server, but none of the machines have been on for years. About time I
> > got rid of them I guess!
>
> I have access to a multi CPU Dec Alpha with loads of RAM, but I don't
> see any benefit from porting besides the potential bugs exposed.

Me neither, but the bug benefit can be quite significant.

> In the end
>
> * Windows x86, x86-64
> * OSX x86, x86-64, ppc, ppc 64
> * Solaris x86, x86-64, Sparc
> * Linux x86, x86-64, Itanium
>
> will cover the vast majority of available hardware out there.

Agreed.

> > But I know from my efforts on ATLChttp://atlc.sourceforge.net/thatbuilding software on multiple

> > platforms tends to find a lot of bugs, which don't show up on platform
> > A, but the bugs are there, ready to surface at some later date. ATLC
> > has been built on many platforms including a Sony Playstation and a
> > Cray supercomputer.
>
> I agree with you that this is a big benefit of porting to
> "miscellaneous" platforms and the port to Linux/ppc for example has
> turned up some interesting bugs that later popped up elsewhere (#1337
> is a good example). That being said once we have the high priority
> port targets working [basically the list above] I am more than
> interested to port to something else provided you gave a shell account
> for me to play with. But we do cover quite a large range of hardware
> and finding targets that are viable is getting harder and harder. And
> it doesn't look like we are running out of bugs to fix anytime soon ;)
>
> Cheers,
>
> Michael

To be honest, I can't be bothered to get these machines out of
mothballs. I think the HP has a partially installed OS, as I started
to upgrade it, but got distracted and do had to leave it.

I do know one guy who is interested in Mathematical software and runs
HP-UX. He has run Mathematica on HP-UX anyway. He might be interested
in doing a port, but I don't know. It's not something I have too much
interest in, but I do feel the potential to undercover bugs is quite
significant.

[mabshoff]

On Jun 6, 10:30 am, "Dr. David Kirkby" <david.kir...@onetel.net>
wrote:

> On Jun 6, 9:05 am, mabshoff <mabsh...@googlemail.com> wrote:

Hi David,

> > > * Then Solaris became free and open source.
>
> > Well, you still have to register for the privilege to download
> > security fixes and that is annoying. I am sure that many people once
> > they get Solaris up and running will be turned off by that. Solaris
> > 10's package selection mechanism is a joke [unfulfilled dependencies
> > are not resolved automatically on request, but you can try until you
> > can figure it out :)], but Indiana will hopefully fix that.
>
> There is no big deal in registering. I don't have a problem with that.
> There is no charge for it.

Sure, but when I registered the Sun server was down and I did not get
any updates then. Had I not wanted to run Solaris for the Sage port I
would have wiped it off my partition right then.

> > > BTW, are there any other ports planned, like HP-UX? I have a HP-UX box
> > > here, but it has not been switched on for many years. I also have
> > > tru64 on a Dec Alpha, IRIX on an SGI Octane and AIX on a large IBM
> > > server, but none of the machines have been on for years. About time I
> > > got rid of them I guess!
>
> > I have access to a multi CPU Dec Alpha with loads of RAM, but I don't
> > see any benefit from porting besides the potential bugs exposed.
>
> Me neither, but the bug benefit can be quite significant.
>
> >  In the end
>
> >  * Windows x86, x86-64
> >  * OSX x86, x86-64, ppc, ppc 64
> >  * Solaris x86, x86-64, Sparc
> >  * Linux x86, x86-64, Itanium
>
> > will cover the vast majority of available hardware out there.
>
> Agreed.
>
>
>

> > >  But I know from my efforts on ATLChttp://atlc.sourceforge.net/thatbuildingsoftware on multiple

> > > platforms tends to find a lot of bugs, which don't show up on platform
> > > A, but the bugs are there, ready to surface at some later date. ATLC
> > > has been built on many platforms including a Sony Playstation and a
> > > Cray supercomputer.
>
> > I agree with you that this is a big benefit of porting to
> > "miscellaneous" platforms and the port to Linux/ppc for example has
> > turned up some interesting bugs that later popped up elsewhere (#1337
> > is a good example). That being said once we have the high priority
> > port targets working [basically the list above] I am more than
> > interested to port to something else provided you gave a shell account
> > for me to play with. But we do cover quite a large range of hardware
> > and finding targets that are viable is getting harder and harder. And
> > it doesn't look like we are running out of bugs to fix anytime soon ;)
>
> > Cheers,
>
> > Michael
>
> To be honest, I can't be bothered to get these machines out of
> mothballs. I think the HP has a partially installed OS, as I started
> to upgrade it, but got distracted and do had to leave it.
>
> I do know one guy who is interested in Mathematical software and runs
> HP-UX. He has run Mathematica on HP-UX anyway. He might be interested
> in doing a port, but I don't know. It's not something I have too much
> interest in, but I do feel the potential to undercover bugs is quite
> significant.

I never understood why Mathematica still supports HPUX other for
historical reasons. And I would imagine most HPUX/Itanium boxen would
run non-scientific workloads, i.e. databases.

Cheers,

Michael

[Dr. David Kirkby]

On Jun 6, 10:05 am, mabshoff <mabsh...@googlemail.com> wrote:
> I never understood why Mathematica still supports HPUX other for
> historical reasons. And I would imagine most HPUX/Itanium boxen would
> run non-scientific workloads, i.e. databases.
>
> Cheers,
>
> Michael

Even more puzzling is why Mathematica supports AMD processors on
Solaris x86, but not Intel ones.

http://www.wolfram.com/products/mathematica/platforms/

However, I have found a workaround for that one.

http://www.g8wrb.org/mathematica/#IntelCPU

by changing some of the libraries supplied by Wolfram Research for
versions supplied by Sun with the Forte compiler.

Dave