Re: [eclipse-clp-users] questions on building eclipse 6.0_183 on OpenSolaris

Hi Kish,

Thanks for the reply.

On 06/11/11 11:06 AM, Kish Shen wrote:

> To compile/build ECLiPSe, you should read at least INSTALL,
> which comes with the source, and probably also the ECLiPSe
> Setup guide (in documents/internal/SetupGuide.doc, yes, it
> is a MS word document, but you can also download a pdf from
> www.eclipseclp.org/reports/SetupGuide.pdf).

Yes, I've spent quite a bit of time reading both of those.
(By the way, no problems reading .doc files on modern 
Solaris systems: there is OpenOffice and also VirtualBox, 
which allows you to run real Windows under Solaris.)


> Did you set ARCH? You can't really build ECLiPSe correctly
> without setting ARCH and ECLIPSETHIRDPARTY.

No, I did not explicitly set ARCH, since configure seemed to 
work without it.  But I did do

export ECLIPSETHIRDPARTY=/home/ko/build/Eclipse_6.0_183


> Another point mentioned in the SetupGuide: we do not
> recommend using gcc 4.3 or 4.4 to build ECLiPSe. There is a
> bug/issue in these versions that means the compiled ECLiPSe
> will run significantly (30%+ for most programs) slower than
> it should (because one of the gcc optimisations, computed
> goto, is not done properly), in particular for x86 machines.
> You should use either earlier (e.g. 4.2) or later (4.5)
> versions of gcc which do not have this problem


Yes, I did read that, but gcc 4.3.3 is the only one 
available (pre-built) at this point, and I don't feel like 
building my own.  I use gcc only if I have to, and much 
prefer the Sun compilers (see below).

>>

> The first message about Java interface not supported comes
> from RUNME not finding the relevant files for Java. The
> script looks for the file using a path that has $ARCH in it,
> so if ARCH is not set correctly, then it would not find the
> files, even if they are there.

If the script looks for a path with $ARCH, this may be a 
problem.  The Java installation's standard location is in 
/usr/java.  Under /usr/java there are

bin/	   demo/     jre/  LICENSE  README.html  src.zip
COPYRIGHT  include/  lib/  man/     sample/	 
THIRDPARTYLICENSEREADME.txt

Any suggestions about what to do here?  Maybe link /usr/java 
under $ECLIPSETHIRDPARTY?


> ECLiPSe is not really designed for you to install the
> executable in a different place from the ECLIPSEDIR,
> although it would probably work.
> This is because the executable (eclipse etc.) are not
> standalone, and they need to use compile/source ECLiPSe code
> as part of the runtime.
> It is possible to remove most of the source (this is what
> the binary distributions effectively does).
>
> The eclipse, jeclipse etc. are intended to be installed in a
> bin/$ARCH path (this is the default) in ECLIPSEDIR. The
> $ARCH allows you to install multiple platforms on the same
> file system.
>
> The ECLiPSe setup is done this way because it was developed
> well before the now standard configure method of using
> --prefix etc, and it is rather tricky to change what we have
> into the standard way of doing things.

Hmm, then I'm not sure how I can install it under 
/opt/eclipse/6.0.


> We use some gcc specific features in our code, the most
> important being the computed goto -- the feature that has
> problems in gcc 4.3 and 4.4. This allows the engine of
> ECLiPSe to run much faster. There may also be other places
> where we use gcc specific features, as we have been
> compiling ECLiPSe with gcc only for many years.

Th Sun Studio compilers support computed gotos. Here is an 
excerpt from the documentation of the C compiler:

The C compiler recognizes the extension to C known as 
computed goto. Computed goto enables runtime determination 
of branching destinations. The address of a label can be
acquired by using the ’&&’ operator and assigned to a 
pointer of type void *:
void *ptr;
...
ptr = &&label1;
A later goto statement can branch to label1 through ptr:
goto *ptr;
Because ptr is computed at runtime, ptr can take on the 
address of any label that is in-scope and the goto statement 
can branch to it.
One way of using computed goto is for the implementation of 
a jump table:

static void *ptrarray[] = { &&label1, &&label2, &&label3 };
Now the array elements can be selected by indexing:
goto *ptrarray[i];
Addresses of labels can only be computed from the current 
function scope.

...

>
> The code that uses computed gotos does check if you are
> using gcc, so you can probably try and compile with the Sun
> compiler, but we can make no promises on how far you would get.

Can you outline the (generic) steps needed to try to compile 
with the Sun compilers? E.g. do I need to modify configure, 
or create a new config.$ARCH file?