After sucessfully fixing the BSDs (see last journal entry), I was so foolish to tackle Solaris.
Needless to say, they never work. Maybe it is because the administrators of these machines are clueless, I don't know (but it's consistently the case everywhere: Sourceforge, the various CIP pools in my university, the chair of high-performance computing etc.).
Anyway, the first thing I observe is a broken terminal. There might be a vi around, but it can't be used due to the screwed terminal.
On with compilers. This is where it becomes really ugly. The Solaris machines of sourceforge's compile-farm have two perls installed (5.6.1 which is a progress - usually they have 5.004_something at most, and 5.8.0). 5.6.1 was compiled with cc. However, trying to compile my module didn't work as there is no cc around anywhere. Setting CC=gcc wont work out of the box either since the gcc wont know about some of cc's compiler flags. Alas, changing the Makefile is impossible without a working editor.
So I tried 5.8.0 which was in fact compiled with gcc. That didn't quite work either because neither sun, __sun, __SRV4 nor __srv4__ (note the extremely consistent naming scheme) are defined. I suppose those symbols are only defined when using suncc which I don't have.
In the meantime (I was trying a few things while writing this journal), I did find the cc. It was hidden as /usr/ucb/cc. But would it work? No:
bash-2.05$ perl Makefile.PL CC=/usr/ucb/cc
Writing Makefile for Device::CDROM
bash-2.05$ make
/usr/ucb/cc -c -I. -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -xO3 -xdepend -DVERSION=\"0.01\" -DXS_VERSION=\"0.01\" -KPIC -I/usr/perl5/5.6.1/lib/sun4-solaris-64int/CORE -DDEV_CDROM_BYTEORDER=87654321 -DDEV_CDROM_OS=\"Device::CDROM::solaris\" CDROM.c
/usr/ucb/cc: language optional software package not installed
make: *** [CDROM.o] Error 1
Reason is that /usr/ucb/cc is just a shell script calling the real cc which is - as you may have guessed - not installed.
Part of the problem is that too many companies don't know the difference between an experienced Solaris administrator and an administrator coming from another Unix who's "worked on Solaris before" or just has a certification. And some places just don't have the resources to hire more staff.
But let's not limit this to Solaris. It's also true for the BSD's, AIX, HP/UX, $DISTNAME Linux, and any other OS -- there is simply no substitute for experience for administrators of ANY operating system. Unfortunately, most people don't realize this until disaster strikes.
Re:cat /dev/clue
Dom2 on 2004-03-10T20:55:11
Solaris is not easy to maintain and configure. But Sun will sell more training courses to sysadmins that way...-Dom (ex solaris admin)
Re:cat /dev/clue
ethan on 2004-03-10T21:55:05
This is my impression as well. It might not be the fault of Solaris itself (although there appears to be a correlation between Solaris and badly maintained machines). It's just that over the time fear has begun creaping up inside me when there's the prospect of having to deal with Solaris.
Re:Possibly helpful
jhorwitz on 2004-03-10T16:02:22
That's pretty sweet. So simple, yet so useful.Re:Possibly helpful
ethan on 2004-03-10T21:50:00
Some time ago I tried to make compilation work with it, but it still failed in a way that I didn't understand. More current releases probably work better.
In any way, I am not trying to install my module on Solaris. I am just testing it. Therefore going the hard way is the right thing to do, I think. Thus I know what Solaris users might have to expect when dealing with my modules and I can foresee some of their problems and mention them in the README.
At least I do have some access to Solaris. I wonder about all those other platforms where I can't easily test my modules. I'd love to try them on HPUX or AIX or so. But I wouldn't know where.
Re:Possibly helpful
Alan Burlison on 2004-03-13T22:16:35
The problem is that the current version relies on being used with the version of MakeMaker that shipped with Solaris - if you've updated MakeMaker from CPAN it doesn't work, as the MM guts changed sufficiently to break it. I've submitted a patch to MakeMaker to make it possible to do this in a generic way, but unfortunately the MM that shipped in 5.8.3 didn't include the patch, and in fact the version of MM with the patch in it *still* hasn't shipped:-(
I've included the patch in the perl 5.8.3 I integrated into Solaris 10, and I can probably fake something up to try to apply the patch (it's only 1 line) to the current MM. I'm considering including perlgcc in Solaris 10 as well, so people will be able to use gcc out of the box (and gcc comes on the Companion CD that ships with Solaris).
You can get the companion CD from http://wwws.sun.com/software/solaris/freeware/index.html, or alternatively from www.sunfreeware.com or www.blastwave.org.Re:Possibly helpful
ethan on 2004-03-13T22:57:49
I'm considering including perlgcc in Solaris 10 as well, so people will be able to use gcc out of the box (and gcc comes on the Companion CD that ships with Solaris).
So far, every Solaris machine I touched did in fact have a gcc (luckily so). It is more tricky to find one with SUN's C compiler. I remember that SourceForge's compile-farm once had it, but right now only the gcc appears to be there. That's quite a pity as my stuff seldom compiled out of the box on compilers other than the gcc. For suncc I remember that I needed to use the-Xaswitch (which puts it into ANSI mode IIRC) to get my modules compiled.Re:Possibly helpful
BooK on 2004-03-15T13:57:21
You could try the Compaq^WHP testdrive
