Building Parrot on Solaris

[Andy Dougherty]

On Thu, 30 Oct 2008, Ovid wrote:

> Trying to build Parrot on Solaris:
> 
>   SunOS ioz-dev-pipsv3 5.10 Generic_125101-10 i86pc i386 i86pc
> 
> Downloaded Parrot from http://www.parrotcode.org/release/devel
> 
> When running Configure.pl, got errors like:
> 
>   test_4811: fatal: libdb-4.4.so: open failed: No such file or directory

Sounds like another variant of [perl #38823] -- Configure.pl is blindly 
using the libraries from the perl 5 configuration.

> Running locate revealed that it was in /opt/csw/bdb44/lib/libdb-4.4.so, 
> so I can get a sucessful Configure.pl run with:
> 
>   perl Configure.pl \
>     --linkflags="-L/opt/csw/bdb44/lib -R/opt/csw/bdb44/lib" \
>     --verbose --fatal

I don't know what package put the library there, but it does strike me as 
a bit unusual and less than completely helpful to install a package 
somewhere that the linker does not ordinarily look.  (I see below you had 
to add a matching -I for the compiler as well.)

> The -R is required because Solaris apparently hardcodes taht path into 
> binaries to look up shared libraries at runtime and Configure.pl won't 
> finish without it.  And in just flailing around, I also did the above, 
> setting ldflags to the same value as linkflags (both were set) and got 
> the same result as what follows.

Solaris and Linux have very similar behavior here.  The -L tells ld where 
to look when building the executable.  The -R tells the resulting binary 
where to look to load the shared library.  The -R can be omitted 
if the specified directory is in LD_LIBRARY_PATH or in the small set of 
directories searched by the linker by default. 

> And then gmake bursts into tears.
> 
>   $ gmake
>   Compiling with:
>   xx.c
>   cc -I./include -D_REENTRANT -xO3 -xarch=386 -xspace -xildoff -I/opt/csw/bdb44/include -I/opt/csw/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -g -DHAVE_COMPUTED_GOTO -KPIC -I. -o xx.o -c xx.c
>   src/ops/core_ops_switch.c
>   "core_ops_switch.c", [switch_core]:ube: error: Assert has been violated at '/set/venus/builds.intel-S2/nightly.Thu/intel-S2/lang/ube/graphs/src/scregion.c 305'.

>   cc: ube failed for src/ops/core_ops_switch.c
>   gmake: *** [src/ops/core_ops_switch.o] Error 2

I see two problems here:

1.  You are trying to compile with optimization.  Unless you're using gcc 
on Intel x86, it's quite possible that parrot won't work this way.

2.  You seem to be using an experimental version of Sun's compiler.  (I 
don't recognize the 'venus' label.)  And that experimental version seems 
to be croaking on one of the largest, most complicated files in the parrot 
distribution.  There may well be bugs lurking in there, but the compiler 
also shouldn't fail.

On OpenSolaris with Sun Ceres C 5.10 SunOS_i386 2008/04/04, parrot builds 
ok[*] as long as you don't enable optimizations.  With -fast, it does 
build (provided you disable optimizations for core_ops_cgp.c) but it 
crashes badly, failing about 1400 tests.  I don't know yet if this is a 
bug in parrot, in sun's compiler, or in both.

[*] Well, it won't build with the default perl due to a Storable issue.  
See [perl #59660].  Changing the requirement from '2.13' to '2.12' in 
lib/Parrot/Pmc2c/Pmc2cMain.pm fixes the problem.

-- 
    Andy Dougherty		doughera at lafayette.edu