Date: Wed, 29 Dec 1999 16:22:28 -0800 From: Amancio Hasty <hasty@rah.star-gate.com> To: current@freebsd.org Subject: gcc compiler problem part deux Message-ID: <199912300022.QAA45237@rah.star-gate.com>
next in thread | raw e-mail | index | archive | help
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"
main() {
printf("hello\n");
}
/usr/libexec/cpp has __FreeBSD_ defined --- and this is not
problem.
2. Now a very recent FreeBSD -current
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"
main() {
}
Voila! the "printf " disappeared.
This behavior breaks the XFree86 3.9.17 build because the procedure
to build imake depends on /usr/libexec/cpp defining __FreeBSD__
I patched locally the imake build so just for FreeBSD it adds a
-D__FreeBSD__
I presumed that the latest /usr/libexec/cpp behavior is also going to
break other package. Again for me is not a problem because
after a few hours I managed to circumvent the new /usr/libexec/cpp
feature.
--
Amancio Hasty
hasty@rah.star-gate.com
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199912300022.QAA45237>