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
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.
the pain (Score:1)
you have to make sure you have your own compiled perl using the compiler you actually have. even then ld sometimes bites you in the arse.
the perl installed by default is compiled with the sun compiler. which almost noone actaully has.
it is just pain. and is why im thankful i sysadmin for java developers
cat /dev/clue (Score:1)
Part of the problem is that too many companies don't know the difference between an experienced Solaris administrator and an admini
Re:cat /dev/clue (Score:2)
-Dom (ex solaris admin)
Re:cat /dev/clue (Score:2)
Possibly helpful (Score:2)
Re:Possibly helpful (Score:1)
Re:Possibly helpful (Score:2)
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 abou
Re:Possibly helpful (Score:1)
I've included the patch in the perl 5.8.3 I integrat
Re:Possibly helpful (Score:2)
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 re
Re:Possibly helpful (Score:2)
You could try the Compaq^WHP testdrive [hp.com]
Modern Solaris is a Mixture (Score:1)
If you've always been on a BSD Unix, you have the advantage of living with a Unix who's sys admin structure has been relatively stable.
If you've always been on Linux, you have the advantage of a sys admin structure that is user-driven: the community has taken what makes sense and kept it.
But Solaris (SunOS) has had a long history before Linux and th