From owner-freebsd-current  Wed Dec 29 16:49:25 1999
Delivered-To: freebsd-current@freebsd.org
Received: from rah.star-gate.com (216-200-29-190.snj0.flashcom.net [216.200.29.194])
	by hub.freebsd.org (Postfix) with ESMTP
	id 027EC14F67; Wed, 29 Dec 1999 16:49:22 -0800 (PST)
	(envelope-from hasty@rah.star-gate.com)
Received: from rah.star-gate.com (localhost.star-gate.com [127.0.0.1])
	by rah.star-gate.com (8.9.3/8.9.3) with ESMTP id QAA45447;
	Wed, 29 Dec 1999 16:48:59 -0800 (PST)
	(envelope-from hasty@rah.star-gate.com)
Message-Id: <199912300048.QAA45447@rah.star-gate.com>
X-Mailer: exmh version 2.0.2 2/24/98
To: Mike Smith <msmith@freebsd.org>
Cc: current@freebsd.org
Subject: Re: gcc compiler problem part deux 
In-reply-to: Your message of "Wed, 29 Dec 1999 16:31:34 PST."
             <199912300031.QAA03126@mass.cdrom.com> 
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Wed, 29 Dec 1999 16:48:59 -0800
From: Amancio Hasty <hasty@rah.star-gate.com>
Sender: owner-freebsd-current@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG

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' 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
> > 
> > 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