__i386__ and cpp

__i386__ and cpp

[H.J. Lu]

Hi,

__i386__ has been dropped from cpp in 1996. It
causes a problem for imake since it calls cpp
directly. It would be nice for egcs 1.0.2 to
define __i386__ on all x86 platforms.

Thanks.


-- 
H.J. Lu (hjl@gnu.org)

Re: __i386__ and cpp

[Jim Wilson]

	__i386__ has been dropped from cpp in 1996. It
	causes a problem for imake since it calls cpp
	directly. It would be nice for egcs 1.0.2 to
	define 386 on all x86 platforms.

This occured because the -Di386 option was moved from CPP_PREDEFINES to
CPP_SPEC, and hence it gets defined only if the gcc driver is called.
It does not get defined if cccp is called directly.

imake assumptions about cpp are in general a problem, since the gcc C
preprocessor doesn't do exactly the same thing as the old unix /lib/cpp command
does.  Also, this assumes that we have a separate preprocessor.  Eventually
we would like to integrate the preprocessor with the cc1 binary, and then
we won't have a separate cccp program anymore.

We could solve these problems by making the cpp program be a shell script
that calls `gcc -E' instead of making cpp be a link to the cccp program.
This script could then do other things to make it look more like the /lib/cpp
command, such as using -traditional, if this is desirable.  This was discussed
a few months ago, on bug-gcc I think.

The other problem with getting -Di386 even when -ansi is specified bothers
me more than the imake problem, and definitely needs to be fixed.

Jim

Re: __i386__ and cpp

[Ronald Wahl]

On Tue, 24 Feb 1998, Jim Wilson wrote:

> 	__i386__ has been dropped from cpp in 1996. It
> 	causes a problem for imake since it calls cpp
> 	directly. It would be nice for egcs 1.0.2 to
> 	define 386 on all x86 platforms.
> [...]
> We could solve these problems by making the cpp program be a shell script
> that calls `gcc -E' instead of making cpp be a link to the cccp program.
> This script could then do other things to make it look more like the /lib/cpp
> command, such as using -traditional, if this is desirable.  This was discussed
> a few months ago, on bug-gcc I think.

I attached a small C program which will do this. I use it for quite some
time without problems.

ron

-- 
\ Ronald Wahl --- rwa@informatik.tu-chemnitz.de   \
 \ WWW: http://www.tu-chemnitz.de/~row/            \
  \ Talk: rwa@goliath.csn.tu-chemnitz.de            \
   \ PGP key available by finger to my email address \

Re: __i386__ and cpp

[H.J. Lu]

> We could solve these problems by making the cpp program be a shell script
> that calls `gcc -E' instead of making cpp be a link to the cccp program.
> This script could then do other things to make it look more like the /lib/cpp
> command, such as using -traditional, if this is desirable.  This was discussed
> a few months ago, on bug-gcc I think.
> 

Someone said gcc -E != cpp due to the different default input. Here is
one proposed cpp. Can we also install a cpp script in egcs, at least
as a configure option for Linux?

Thanks.

H.J.
----
#! /bin/sh

exec `gcc -print-prog-name=cpp` ${1+"$@"}

Re: __i386__ and cpp

[Jeffrey A Law]

  In message < 199802250426.UAA07399@rtl.cygnus.com >you write:
  > This occured because the -Di386 option was moved from CPP_PREDEFINES to
  > CPP_SPEC, and hence it gets defined only if the gcc driver is called.
  > It does not get defined if cccp is called directly.
Right.

  > imake assumptions about cpp are in general a problem, since the gcc C
  > preprocessor doesn't do exactly the same thing as the old unix /lib/cpp command
  > does.  Also, this assumes that we have a separate preprocessor.  Eventually
  > we would like to integrate the preprocessor with the cc1 binary, and then
  > we won't have a separate cccp program anymore.
Yup.  But the key point to remember is all these uses of imake are
already entrenched in the community.   If we break them (like we have
until now), then we look bad.

  > We could solve these problems by making the cpp program be a shell script
  > that calls `gcc -E' instead of making cpp be a link to the cccp program.
And I assume change gcc to use "cccp" so as to avoid multiple programs
called "cpp" that do different things.

You also have to be careful to get quoting rules correct -- I tried
the same thing a few years ago and ended up writing some real C code
to ensure quoting in args was handled correctly.

jeff

Re: __i386__ and cpp

[Jeffrey A Law]

  In message <u9ra4qn88e.fsf@yorick.cygnus.com>you write:
  > > You also have to be careful to get quoting rules correct -- I tried
  > > the same thing a few years ago and ended up writing some real C code
  > > to ensure quoting in args was handled correctly.
  > 
  > I find that ${1:+"$@"} works fine.
Fine.  Just relaying some previous experiences :-)

jeff

Re: __i386__ and cpp

[Jeffrey A Law]

  In message <m0y3T4L-0004ecC@ocean.lucon.org>you write:
  > __i386__ has been dropped from cpp in 1996. It
  > causes a problem for imake since it calls cpp
  > directly. It would be nice for egcs 1.0.2 to
  > define __i386__ on all x86 platforms.
Actually, it looks like Imake is involing /lib/cpp, which is
a symlink into the gcc-2.7 gcc-lib directory on my linux boxes.

So how exactly are folks getting the egcs cpp when they're using
imake?

jeff

Re: __i386__ and cpp

[H.J. Lu]

> 
> 
>   In message <m0y3T4L-0004ecC@ocean.lucon.org>you write:
>   > __i386__ has been dropped from cpp in 1996. It
>   > causes a problem for imake since it calls cpp
>   > directly. It would be nice for egcs 1.0.2 to
>   > define __i386__ on all x86 platforms.
> Actually, it looks like Imake is involing /lib/cpp, which is
> a symlink into the gcc-2.7 gcc-lib directory on my linux boxes.
> 
> So how exactly are folks getting the egcs cpp when they're using
> imake?
> 

How about people who uses egcs 1.0.1 as their only compiler :-)?
They will make such a link.

-- 
H.J. Lu (hjl@gnu.org)

Re: __i386__ and cpp

[Jeffrey A Law]

  In message < m0y9Xl6-00058fC@ocean.lucon.org >you write:
  > > 
  > > 
  > >   In message <m0y3T4L-0004ecC@ocean.lucon.org>you write:
  > >   > __i386__ has been dropped from cpp in 1996. It
  > >   > causes a problem for imake since it calls cpp
  > >   > directly. It would be nice for egcs 1.0.2 to
  > >   > define __i386__ on all x86 platforms.
  > > Actually, it looks like Imake is involing /lib/cpp, which is
  > > a symlink into the gcc-2.7 gcc-lib directory on my linux boxes.
  > > 
  > > So how exactly are folks getting the egcs cpp when they're using
  > > imake?
  > > 
  > 
  > How about people who uses egcs 1.0.1 as their only compiler :-)?
  > They will make such a link.
So, do we just provide the script in the source dir for the user to
install, or do we actually arrange to install it in the library
directory?

jeff

Re: __i386__ and cpp

[H.J. Lu]

>   > > In fact, it seems to me this should effect all systems.  So I
>   > > think the criteria for installing the wrapper ought to be
>   > > solely based on a configure time option.  Can you do that?
>   > > 
>   > 
>   > How about we install cpp when host == target == build and
>   > prefix == /usr? I can provide a patch to do it.
> Why do you want these conditions?
> 

1. It doesn't make sense to install cpp for cross-compiler. Maybe
it should be host == target.
2. If prefix != /usr, that may indicate there is another C compiler
under /usr and a cpp linked to it.

So host == target and prefix == /usr mean we are the default
C compiler.

Another choice it to add --install-cpp to configure. I can
try that too. But that will need more work to modify egcs/configure
and gcc/configure.in.

Either way is ok with me. Let me know which one we want.

Thanks.


-- 
H.J. Lu (hjl@gnu.org)

Re: __i386__ and cpp

[Jeffrey A Law]

  In message < m0yATyV-00058JC@ocean.lucon.org >you write:
  > 1. It doesn't make sense to install cpp for cross-compiler. Maybe
  > it should be host == target.
I disagree.  I might have a cross build environment that wants to
call cpp.  In fact, I've had to do this before.

  > 2. If prefix != /usr, that may indicate there is another C compiler
  > under /usr and a cpp linked to it.
Right.  But if we're providing cpp, it should be provided under
$prefix regardless of the value of $prefix.  Anything else is
flat out wrong.  Also see #1.

  > Another choice it to add --install-cpp to configure. I can
  > try that too. But that will need more work to modify egcs/configure
  > and gcc/configure.in.
I would prefer a configure time option.

jeff

Re: __i386__ and cpp

[Jeffrey A Law]

  In message < Pine.LNX.3.96.980303094106.14597B-100000@panic.can.seawood.org >yoite:
  > Is this script really needed?  Are there any other cases of programs
  > checking for i386 via cpp?  If imake is the only one, why go thru the
  > trouble of the script for one specific case?  
Well, in my past experience a few programs want to do dorky things
like "/lib/cpp blah blah blah".  imake is the most popular, but I
don't think it's the only program that might depend on this behavior.

Also, this (bogus) imake behavior is entrenched on many of the
systems where we want egcs to "just dropin and work".  If we can't
build X without user hackery, then IMHO, we've failed to provide
a drop in replacement.
 
jeff

Re: __i386__ and cpp

[Jeffrey A Law]

  In message < m0y9uUu-00058fC@ocean.lucon.org >you write:
  > Assuming script does work, I have a version which I have verified by
  > building XFree86 3.3.2,  I suggest we install it only if it is
  > asked for. By that, I mean prefix == /usr and it is on Linux. We can
  > add a file "install.cpp" in config. Linux can adds it to Makefile.
  > Then it will check if prefix == /usr before installing it. I prefer
  > to put the script in /usr/bin and make a symlink to /lib. I can provide
  > a whole patch for it.
Well, doesn't this problem effect non-Linux machines too?  Like
freebsd-elf?

In fact, it seems to me this should effect all systems.  So I
think the criteria for installing the wrapper ought to be
solely based on a configure time option.  Can you do that?

jeff

Re: __i386__ and cpp

[Jeffrey A Law]

  In message < m0yATfS-00058JC@ocean.lucon.org >you write:
  > > 
  > > 
  > >   In message < m0y9uUu-00058fC@ocean.lucon.org >you write:
  > >   > Assuming script does work, I have a version which I have verified by
  > >   > building XFree86 3.3.2,  I suggest we install it only if it is
  > >   > asked for. By that, I mean prefix == /usr and it is on Linux. We can
  > >   > add a file "install.cpp" in config. Linux can adds it to Makefile.
  > >   > Then it will check if prefix == /usr before installing it. I prefer
  > >   > to put the script in /usr/bin and make a symlink to /lib. I can provi
  > de
  > >   > a whole patch for it.
  > > Well, doesn't this problem effect non-Linux machines too?  Like
  > > freebsd-elf?
  > > 
  > > In fact, it seems to me this should effect all systems.  So I
  > > think the criteria for installing the wrapper ought to be
  > > solely based on a configure time option.  Can you do that?
  > > 
  > 
  > How about we install cpp when host == target == build and
  > prefix == /usr? I can provide a patch to do it.
Why do you want these conditions?

jeff

Re: __i386__ and cpp

[H.J. Lu]

> 
> 
>   In message < m0y9uUu-00058fC@ocean.lucon.org >you write:
>   > Assuming script does work, I have a version which I have verified by
>   > building XFree86 3.3.2,  I suggest we install it only if it is
>   > asked for. By that, I mean prefix == /usr and it is on Linux. We can
>   > add a file "install.cpp" in config. Linux can adds it to Makefile.
>   > Then it will check if prefix == /usr before installing it. I prefer
>   > to put the script in /usr/bin and make a symlink to /lib. I can provide
>   > a whole patch for it.
> Well, doesn't this problem effect non-Linux machines too?  Like
> freebsd-elf?
> 
> In fact, it seems to me this should effect all systems.  So I
> think the criteria for installing the wrapper ought to be
> solely based on a configure time option.  Can you do that?
> 

How about we install cpp when host == target == build and
prefix == /usr? I can provide a patch to do it.


-- 
H.J. Lu (hjl@gnu.org)

Re: __i386__ and cpp

[H.J. Lu]

>   > Another choice it to add --install-cpp to configure. I can
>   > try that too. But that will need more work to modify egcs/configure
>   > and gcc/configure.in.
> I would prefer a configure time option.
> 

I will add --enable-cpp to configure. I will send a patch by
this weekend.


-- 
H.J. Lu (hjl@gnu.org)

Re: __i386__ and cpp

[Christopher Seawood]

On Tue, 3 Mar 1998, Jeffrey A Law wrote:

> 
>   In message < m0y9Xl6-00058fC@ocean.lucon.org >you write:
>   > > 
>   > > 
>   > >   In message <m0y3T4L-0004ecC@ocean.lucon.org>you write:
>   > >   > __i386__ has been dropped from cpp in 1996. It
>   > >   > causes a problem for imake since it calls cpp
>   > >   > directly. It would be nice for egcs 1.0.2 to
>   > >   > define __i386__ on all x86 platforms.
>   > > Actually, it looks like Imake is involing /lib/cpp, which is
>   > > a symlink into the gcc-2.7 gcc-lib directory on my linux boxes.
>   > > 
>   > > So how exactly are folks getting the egcs cpp when they're using
>   > > imake?
>   > > 
>   > 
>   > How about people who uses egcs 1.0.1 as their only compiler :-)?
>   > They will make such a link.
> So, do we just provide the script in the source dir for the user to
> install, or do we actually arrange to install it in the library
> directory?

Is this script really needed?  Are there any other cases of programs
checking for i386 via cpp?  If imake is the only one, why go thru the
trouble of the script for one specific case?  

From the discussions that I've seen so far, the problem appears to be more
with the imake source than gcc.  I've rarely seen imake invoked directly. 
Wouldn't it be much easier to edit xmkmf and add -Di386 to the args list?

Also, I'm not sure if it's been mentioned, but when XFree86 is recompiled
with egcs, the problem goes away as imake defines -Di386 itself.

- cls

Re: __i386__ and cpp

[H.J. Lu]

> 
> 
>   In message < m0y9Xl6-00058fC@ocean.lucon.org >you write:
>   > > 
>   > > 
>   > >   In message <m0y3T4L-0004ecC@ocean.lucon.org>you write:
>   > >   > __i386__ has been dropped from cpp in 1996. It
>   > >   > causes a problem for imake since it calls cpp
>   > >   > directly. It would be nice for egcs 1.0.2 to
>   > >   > define __i386__ on all x86 platforms.
>   > > Actually, it looks like Imake is involing /lib/cpp, which is
>   > > a symlink into the gcc-2.7 gcc-lib directory on my linux boxes.
>   > > 
>   > > So how exactly are folks getting the egcs cpp when they're using
>   > > imake?
>   > > 
>   > 
>   > How about people who uses egcs 1.0.1 as their only compiler :-)?
>   > They will make such a link.
> So, do we just provide the script in the source dir for the user to
> install, or do we actually arrange to install it in the library
> directory?
> 

Assuming script does work, I have a version which I have verified by
building XFree86 3.3.2,  I suggest we install it only if it is
asked for. By that, I mean prefix == /usr and it is on Linux. We can
add a file "install.cpp" in config. Linux can adds it to Makefile.
Then it will check if prefix == /usr before installing it. I prefer
to put the script in /usr/bin and make a symlink to /lib. I can provide
a whole patch for it.


-- 
H.J. Lu (hjl@gnu.org)

Re: __i386__ and cpp

[Manfred Hollstein]

On Tue, 3 March 1998, 01:58:16, law@cygnus.com wrote:

 > 
 >   In message < m0y9Xl6-00058fC@ocean.lucon.org >you write:
 >   > > 
 >   > > 
 >   > >   In message <m0y3T4L-0004ecC@ocean.lucon.org>you write:
 >   > >   > __i386__ has been dropped from cpp in 1996. It
 >   > >   > causes a problem for imake since it calls cpp
 >   > >   > directly. It would be nice for egcs 1.0.2 to
 >   > >   > define __i386__ on all x86 platforms.
 >   > > Actually, it looks like Imake is involing /lib/cpp, which is
 >   > > a symlink into the gcc-2.7 gcc-lib directory on my linux boxes.
 >   > > 
 >   > > So how exactly are folks getting the egcs cpp when they're using
 >   > > imake?
 >   > > 
 >   > 
 >   > How about people who uses egcs 1.0.1 as their only compiler :-)?
 >   > They will make such a link.
 > So, do we just provide the script in the source dir for the user to
 > install, or do we actually arrange to install it in the library
 > directory?

Well I'd suppose to leave this on the distributor. Tell Debian, Redhat,
etc. to install the following script as /lib/cpp:

------------ Cut here: /lib/cpp ----------------
#! /bin/sh

# set -x

# First lets look if there is a file argument; otherwise we'll need to instruct
# gcc to read from stdin.

got_file=no
for f
do
	[ -f "$f" ] && { got_file=yes; break; }
done

# The '-x c' is necessary to suppress error message like
#  gcc: /home/manfred//.holiday: linker input file unused since linking not done
# for files with unknown extensions.
exec gcc -x c -E ${1+"$@"} `[ $got_file = no ] && echo -`
--------- Cut here: end of /lib/cpp -------------

How about that? I'm using this script for a cpp/imake based GUI development
environment I developed for my employer, hence I believe it's fool-proof, now.

Manfred

Re: __i386__ and cpp

[Jason Merrill]

>>>>> Jeffrey A Law <law@cygnus.com> writes:

>> We could solve these problems by making the cpp program be a shell script
>> that calls `gcc -E' instead of making cpp be a link to the cccp program.

> You also have to be careful to get quoting rules correct -- I tried
> the same thing a few years ago and ended up writing some real C code
> to ensure quoting in args was handled correctly.

I find that ${1:+"$@"} works fine.

Jason