[Ecls-list] Compilation on solaris

Dr. David Kirkby david.kirkby at onetel.net
Sat Aug 22 22:41:45 UTC 2009

Juan Jose Garcia-Ripoll wrote:
> On Sat, Aug 22, 2009 at 11:42 PM, Dr. David
> Kirkby<david.kirkby at onetel.net> wrote:
>> Sort of, but since I set both those machine up, and tweaked the setups
>> somewhat to make Sage build, I would not be surprised if others had more
>> trouble.
> You mean that you tweaked the Solaris setup to have more
> gnu-compatible stuff around, I presume.

Yes. In particular making sure the GNU version of 'make' which is 
/usr/sfw/bin/gmake is early in the path with a name 'make'

(It should be noted that many GNU tools exists in /usr/sfw/bin, and all 
have the letter 'g' in front. So 'gld' is the GNU linker, 'gas' is the 
GNU assember, 'gtar' is the GNU tar etc. )

>> If I use the 'Sun' make command, then a lot of ECL builds (which surprises
>> me somewhat, as the Sun 'make' command is pretty dumb). But the ECL build
>> finally fails with:
>> make: Fatal error: Don't know how to make target `main.o'
>> Current working directory /export/home/drkirkby/ecl-9.8.4/build/c
>> *** Error code 1
>> make: Fatal error: Command failed for target `libeclmin.a'
>> Current working directory /export/home/drkirkby/ecl-9.8.4/build
>> *** Error code 1
>> make: Fatal error: Command failed for target `all'
> Sounds like a problem with the double-suffix rules. Solaris make does
> not seem to understand them properly. I have set up another build
> process, but this time putting /usr/ccs/bin in front of the PATH, so
> that it gets that version of "make" first. I will see what changes I
> have to make in ecl/src/Makefile.in

I was under the impression the autotools relied on there being GNU make 

>> The way I would suggest getting around this is to tell people to set a
>> variable 'MAKE' to be the name of a command which is GNU make. Or
> I would rather avoid this and simplify the Makefile instead.

Great if it can be done.

>> In a few days, I will be setting up a machine with the very first release of
>> Solaris 10 on it. If I gave you an account on that, before I put any
>> software on it, you might get a different perspective. I believe you will
>> hit some problems.
> I already hit them with the OpenSolaris/Intel I am running the tests
> in. But there the ordinary "make" from Solaris is doing fine. Maybe
> they fixed something in moving from v10 to v11?

I doubt it. I believe the tools in /usr/ccs/bin are there for backward 
compatibility, so I doubt Sun would fix any 'bugs' in them, in case the 
'bugs' were used and fixing them would break peoples code.

>> This setup would not be suitable for a build farm, but it might be useful
>> for occasional use. It's not a fast machine (only 450 MHz), nor does it have
>> a fast network connection, but it might be ok for a test.
> It would be fun to try. And I am used to slow builds -- mark2 takes
> about 15 minutes to configure ECL, my virtualbox with mingw takes
> about half an hour :-)

I have suffered some lightning damage recently and lost 3 Sun computers. 
I need to sort out a few things. But it has always been my intension to 
have something running the first release of Solaris 10 so a binary for 
Sage could be built on that, and it run on any release of Solaris 10. 
Building a binary on Solaris 10 update 7 would not guarantee it would 
run on earlier releases of Solaris 10.

>> It's very common to need to use the GNU make command on Solaris. What seems
>> to be an issue in ECL is getting all components to use it. They start to use
>> the Sun make command.
> I don't know whether the information is lost when configuring sub-components.

That might be an issue.

I'll do a fresh, but complete install of Solaris and give you an 
account. I'll give you the standard shell, the standard path, and see 
how you get on. Give me a few days for that.

> Juanjo

More information about the ecl-devel mailing list