Re: RE:DGUX Unix - GCC-2.95.x

[Manfred Hollstein <mhollstein at cygnus dot com>]

Hi Takis,

I  can fully understand  your emotions  in that  a  previously working
package   suddenly  stopped working  simply   due  to a  (probably not
obvious) change  in  a totally  different package.   I recognized this
myself, when the  new cpp failed  to pre-define some  macros which the
old one did and which  I had been using in  my WMGR.rc file generating
framework for years...

The reason behind this, which has been explained by Jeff Law as

  "To be ansi  compliant",

might not be acceptable to you, because your /lib/cpp doesn't complain
about missing "i386" macros etc. But, as Jeff was pointing out, ANSI-C
requires  particular  constraints  for symbols   polluting  the global
namespace; as such, it defines names starting  with "__" as reserved -
and reserved names are not allowed  to start without "__". This means,
your /lib/cpp isn't ANSI compliant.

Since the C preprocessor (/lib/cpp) isn't defined (or required) by any
standard at all (just consider --enable-c-cpplib), it is up to you (or
any package maintainer  relying on the existance  of  such a  file) to
provide a proper version.

Looking at your email address, it seems you are working with the XFree
consortium; please let me suggest that XFree's (and probably all newer
X) release's imake config files will be fixed *not* to use macros like
"i386".  I know, since there are various non-compliant C compilers and
preprocessors around,   it  might be necessary  to  change   all those
occurrences like

  #ifdef i386
  ...

into

  #if defined (__i386__) || defined (i386)
  ...

It isn't the  right solution to  request some particular  feature from
the compiler, only because it has been misused in the past.

l8er
manfred

On Fri, 20 August 1999, 00:28:01, takis@XFree86.org wrote:

 > 
 > 
 > 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.
 > 
 > 

 Manfred Hollstein			<mailto:mhollstein@cygnus.com>
 Cygnus Solutions			     phone: +49-(0)7044-910079
 Hindenburgstr. 13/1			    mobile: +49-(0)170-3436257
 75446 Wiernsheim, Germany		       fax: +49-(0)7044-910049