* Re: __i386__ and cpp
1998-03-03 2:17 ` Jeffrey A Law
@ 1998-03-05 16:38 ` Manfred Hollstein
1998-03-05 16:38 ` Christopher Seawood
1998-03-05 16:38 ` H.J. Lu
2 siblings, 0 replies; 20+ messages in thread
From: Manfred Hollstein @ 1998-03-05 16:38 UTC (permalink / raw)
To: law; +Cc: hjl, egcs, 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
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: __i386__ and cpp
1998-03-03 2:17 ` Jeffrey A Law
1998-03-05 16:38 ` Manfred Hollstein
@ 1998-03-05 16:38 ` Christopher Seawood
1998-03-05 15:33 ` Jeffrey A Law
1998-03-05 16:38 ` H.J. Lu
2 siblings, 1 reply; 20+ messages in thread
From: Christopher Seawood @ 1998-03-05 16:38 UTC (permalink / raw)
To: Jeffrey A Law; +Cc: H.J. Lu, egcs
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
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: __i386__ and cpp
1998-03-05 16:38 ` Christopher Seawood
@ 1998-03-05 15:33 ` Jeffrey A Law
0 siblings, 0 replies; 20+ messages in thread
From: Jeffrey A Law @ 1998-03-05 15:33 UTC (permalink / raw)
To: Christopher Seawood; +Cc: H.J. Lu, egcs
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
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: __i386__ and cpp
1998-03-03 2:17 ` Jeffrey A Law
1998-03-05 16:38 ` Manfred Hollstein
1998-03-05 16:38 ` Christopher Seawood
@ 1998-03-05 16:38 ` H.J. Lu
1998-03-05 15:33 ` Jeffrey A Law
2 siblings, 1 reply; 20+ messages in thread
From: H.J. Lu @ 1998-03-05 16:38 UTC (permalink / raw)
To: law; +Cc: egcs
>
>
> 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)
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: __i386__ and cpp
1998-03-05 16:38 ` H.J. Lu
@ 1998-03-05 15:33 ` Jeffrey A Law
1998-03-05 15:33 ` H.J. Lu
0 siblings, 1 reply; 20+ messages in thread
From: Jeffrey A Law @ 1998-03-05 15:33 UTC (permalink / raw)
To: H.J. Lu; +Cc: egcs
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
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: __i386__ and cpp
1998-03-05 15:33 ` Jeffrey A Law
@ 1998-03-05 15:33 ` H.J. Lu
1998-03-05 15:33 ` Jeffrey A Law
0 siblings, 1 reply; 20+ messages in thread
From: H.J. Lu @ 1998-03-05 15:33 UTC (permalink / raw)
To: law; +Cc: egcs
>
>
> 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)
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: __i386__ and cpp
1998-03-05 15:33 ` H.J. Lu
@ 1998-03-05 15:33 ` Jeffrey A Law
1998-03-05 15:33 ` H.J. Lu
0 siblings, 1 reply; 20+ messages in thread
From: Jeffrey A Law @ 1998-03-05 15:33 UTC (permalink / raw)
To: H.J. Lu; +Cc: egcs
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
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: __i386__ and cpp
1998-03-05 15:33 ` Jeffrey A Law
@ 1998-03-05 15:33 ` H.J. Lu
1998-03-05 15:33 ` Jeffrey A Law
0 siblings, 1 reply; 20+ messages in thread
From: H.J. Lu @ 1998-03-05 15:33 UTC (permalink / raw)
To: law; +Cc: egcs
> > > 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)
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: __i386__ and cpp
1998-03-05 15:33 ` H.J. Lu
@ 1998-03-05 15:33 ` Jeffrey A Law
1998-03-05 15:33 ` H.J. Lu
0 siblings, 1 reply; 20+ messages in thread
From: Jeffrey A Law @ 1998-03-05 15:33 UTC (permalink / raw)
To: H.J. Lu; +Cc: egcs
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
^ permalink raw reply [flat|nested] 20+ messages in thread