I wrote:
>Last time I checked (I haven't moved to the latest gcc, so I can't
>confirm it there), one significant difference between 'cc -E' and
>/usr/libexec/cpp was that the latter would read from a pipe, whilst
>the former wouldn't.
It seems I was wrong. As several people have pointed out, bot
On Fri, 31 Dec 1999, Peter Jeremy wrote:
> Last time I checked (I haven't moved to the latest gcc, so I can't
> confirm it there), one significant difference between 'cc -E' and
> /usr/libexec/cpp was that the latter would read from a pipe, whilst
> the former wouldn't. This can make converting
In article <[EMAIL PROTECTED]>, Peter
Jeremy <[EMAIL PROTECTED]> wrote:
> Last time I checked (I haven't moved to the latest gcc, so I can't
> confirm it there), one significant difference between 'cc -E'
> and /usr/libexec/cpp was that the latter would read from a pipe,
> whilst the former would
Last time I checked (I haven't moved to the latest gcc, so I can't
confirm it there), one significant difference between 'cc -E' and
/usr/libexec/cpp was that the latter would read from a pipe, whilst
the former wouldn't. This can make converting to 'cc -E' a
non-trivial exercise.
Peter
To Uns
The usage came about oh about 8 years ago with the very first port
of X to 386bsd by yours truly 8)
Don't forget I did fix the problem on my X build and I am running
the latest XFree86 3.9.xx on my other box.
Take Care
> > Forgot to post about this new feature of /usr/libexec/cpp :
>
>
> Forgot to post about this new feature of /usr/libexec/cpp :
NO ONE should have ever have been using /usr/libexec/cpp directly. I
have no idea where this usage came from. /usr/bin/cpp should have been
used.
> 2. Now a very recent FreeBSD -current
> gcc -v
> Using builtin specs.
> gcc version
On Wed, 29 Dec 1999, Amancio Hasty wrote:
> There are packages such as XFree86 which called directly the installed
> cpp. Those packages which rely on the old behavior of /usr/libexec/cpp
> for instance defining __FreeBSD__ are now broken .
... and they will be fixed through bug reports. We no
It is more of a question of whether the packages for FreeBSD expect
/usr/libexec/cpp to define __FreeBSD__ and in my case XFree86.
Once I managed to find out what was wrong it was indeed easy for
me to fix. If the "other" applications managed to compile correctly
on FreeBSD because of /usr/libexec
> There are packages such as XFree86 which called directly the installed
> cpp. Those packages which rely on the old behavior of /usr/libexec/cpp
> for instance defining __FreeBSD__ are now broken .
XFree86 is trivial to patch, since it already supports this behaviour (see
our port), and other a
There are packages such as XFree86 which called directly the installed
cpp. Those packages which rely on the old behavior of /usr/libexec/cpp
for instance defining __FreeBSD__ are now broken .
>
> This was discussed weeks ago, and the new behaviour is correct. You
> should be using 'cc -E' i
This was discussed weeks ago, and the new behaviour is correct. You
should be using 'cc -E' instead.
>
> Forgot to post about this new feature of /usr/libexec/cpp :
> 1. Test file
> foo.c
>
> main() {
> #ifdef __FreeBSD__
> printf("hello\n");
> #endif
> }
>
> 1. old freebsd-current
>
Forgot to post about this new feature of /usr/libexec/cpp :
1. Test file
foo.c
main() {
#ifdef __FreeBSD__
printf("hello\n");
#endif
}
1. old freebsd-current
2. gcc -v
Using builtin specs.
gcc version egcs-2.91.66 19990314 (egcs-1.1.2 release)
/usr/libexec/cpp foo.c
# 1 "foo.c"
12 matches
Mail list logo
