PORT of GCC 3.0.4 to ix86 DG/UX Unix

[Takis Psarogiannakopoulos <takis at XFree86 dot Org>]

The source code can be found at:

ftp public.xfree86.org
login: ftp
password: your email
cd pub/XFree86/4.2.0/binaries/DGUX-ix86/GCC-3.0.4-DGUX
bin
get gcc-dgux-3.0.4.tar.gz (source code).
quit

In the same location one can find some prebuild binaries 
under the name DGUX-GCC-3.0.4-binaries.tar.gz and some
README files for building/installation. 

Some comments/remarks:

1) Sicne 3.0.4 has not anymore two cpp binaries with the
same name! it fits just fine to the traditional DG/UX's
elink mechanism. Thank you for this implementation.

2) Both the Java compiler (aka gcj) and libjava both are fully
functional in addition of course to the c++/g++ one. 
Unfortunately the GC garbage collector is too old and cannot
be made functional in DG/UX. I have submitted a patch for DG/UX
to Hans Boehm for its latest GC6. It will be great if there 
was to be a 3.0.5 release to use these new GC. 

3) The GCC-3.0.4 for DG/UX uses the sjlj exception model.
This is because of the fact, that, as I learned recently,
basically apart from Linux, no other OS can use md_frame 
exception model and have also a functional libjava! 
Since, no other OS has an MD_FALLBACK_FRAME_STATE_FOR defined
in the host.h file. While I will work to produce one 
such macro for DG/UX it seems to me a great price to pay
for making libjava functional. In C++ the sjlj exception 
model is slower from md_frame and the thing is that the 
C++ compiler works just fine in DG/UX (with md_frame).

It will be great if we could implement a two-flavor libgcc
one used in libjava (and from gcj) and another used from the
C,C++ so we could have md_frame exceptions for C,C++ and 
sjlj exceptions for Java.

4) In libjava/libgcj.spec.in we find:

*lib: -lgcj -lm @LIBICONV@ @GCSPEC@ @THREADSPEC@ @ZLIBSPEC@ @SYSTEMSPEC@  
%(libgcc) %(liborig)

This seems to me wrong. In DG/UX we use the thread model dgux386. Hence
libgcc has weak symbols for libthread.so. The configure script will
detect THREADSPEC as "-lrte -lthread". Clearly the order above it is
incorrect!
Should be:
 
*lib: -lgcj -lm @LIBICONV@ @GCSPEC@ @ZLIBSPEC@ @SYSTEMSPEC@ 
%(libgcc) @THREADSPEC@ %(liborig)
 
in order to link correctly (for DG/UX at least)!
Note that if --enable-threads is not used when we building gcc then
clearly the above issue doesnt matter since libgcc doesnt have any
thread symbols. But if we use --enable-threads it it very important.

5) The source code contains also a full port of libtool to DG/UX
(since essentailly libtool is a part of GCC-3.0.4)
Alexandre Oliva may want to integrate this to the source tree of 
libtool.

6) Someone may want to explain to me in a provate email the fucntion 
SANITY macro. (perhaps the guy who implemeted) It fails stangely in
DG/UX but the GCC build goes on just fine. The env is sane!

7) *If* there is a need, someone please can send me the necessary docs 
so that you can check in (some of) the changes to the official source
tree?

8) Trying the latest 3.1 CVS branch libgcc.a has been separated in an
innocent libgcc.a and an libgcc_eh.a. When building libjava we
need to use this second libgcc_eh.a in the line

*lib: -lgcj -lm @LIBICONV@ @GCSPEC@ @THREADSPEC@ @ZLIBSPEC@ @SYSTEMSPEC@
%(libgcc) %(liborig)

since the libgcc.a has no exception/thread code. Please someone to
fix this. 

9) A very *big* thank you to Martin v. Loewis for its help and his
patience to explain things. He has passed to me a great deal of
knowledge about the GCC compiler. 
Also I would like to thank Andrew Haley for the email-conversations
that we had about libjava these last couple of months.

Regards,
Takis