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>