DGUX Unix - GCC-2.95.x

[Takis Psarogiannakopoulos]

Hello,

On Thu, 19 Aug 1999, Jeffrey A Law wrote:

>   In message
< Pine.BSF.4.05.9908191138250.5592-100000@public.xfree86.org >you $> ite:
> Probably because your mail was so disjointed and unreadable that nobody
> wanted to bother to try and understand it.
>

OK. I am sorry for this I did wrote it in a rush.

> Certainly not on purpose.  

OK.

> And I would *strongly* disagree that
> gcc-2.8.1 actually worked correctly on dgux.  The dgux port is a
> complete and total mess.  I considered trying to get the various fixes
> into gcc-2.95, but there were many things which were more important than
> the dgux port.
>

How many DG/ux machines do you have in cygnus? I have done also the 
gdb port, and I've been told that you dont have any DG/ux machines.
gcc-2.8.1 works in DG/ux ix86. Perhaps needs one-two more changes 
than the one in GNU but after that it performs well. I am compiling 
X11R6, All the GNU toolkit , KDE, and whatever. More than 600 MBs
binaries. Dont confuse the problems of gcc-2.8.1 to work in coordination
with the DG/ux as and produce dwarf-2 with the general functionality
of gcc. Only recently I found  that QT-2.0.1 doesnt compile correctly
with gcc-2.8.1 (c++) That is the only real serious bug that I am aware.
Disassembling the .s files reveals the fix though.


> To be ansi compliant.

OK. My problem is not that since the external cpp (xcpp) works ok.
(has almost all the features that I need). Only I cannot copy it in 
the gcc-local-dir since it will overwrite the "hidden version of cpp"
Typically in DG/ux we make a dir , say gcc-dg-2.95, with all the files
of gcc inside ie, gcc,c++,g++, libgcc,libobjc, cc1, cc1plus, cc1obj,
specs, cpp, crt* files , and we copy this directory to the elink.
Then the DG/ux elink will arrange to point from there the tools 
to the actual "user path".
What I am saying is that in gcc.2.8.1 there was only _one_ "hidden"
cpp , that was living inside there. So if you now introducing a
change it will be good to leave this feature alone and just make
a "hidden_cpp" (or what ever other name you want) in gcc-local-dir.
If for some reason DG has arrange to access this cpp through its
elink the correct thing for the developer is not to change it and 
then say to DGux users to contact DG (EMC) to change this particular
feature...


> imake should not depend on -Di386, it is an ANSI violation for
> the compiler to define -Di386.
>
???...

imake compiles with DGUX native cc. DG/UX cc will invoke cpp in the
gcc-local-dir (in more detail: the /lib/cpp  that points through
the elink mechanism to an executable named cpp in the gcc-local-dir).
As the "hidden" 2.95 cpp misses features, cc will halt with errors.
If we had the sources of DG/ux we would be able of course to modify 
the elink binaries  in /usr/opt/sdk/bin to invoke the tools of our
choice. But I guess we dont have this option ...
   

Regards,
T.