From owner-freebsd-ports Tue Jul 7 13:19:58 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id NAA28186 for freebsd-ports-outgoing; Tue, 7 Jul 1998 13:19:58 -0700 (PDT) (envelope-from owner-freebsd-ports@FreeBSD.ORG) Received: from alpo.whistle.com (alpo.whistle.com [207.76.204.38]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id NAA28180; Tue, 7 Jul 1998 13:19:56 -0700 (PDT) (envelope-from terry@whistle.com) Received: (from daemon@localhost) by alpo.whistle.com (8.8.5/8.8.5) id NAA14850; Tue, 7 Jul 1998 13:17:33 -0700 (PDT) Received: from tlambert.whistle.com(207.76.205.208) via SMTP by alpo.whistle.com, id smtpd014842; Tue Jul 7 20:17:30 1998 Message-ID: <35A281E8.FCE@whistle.com> Date: Tue, 07 Jul 1998 13:15:36 -0700 From: Terry Lambert Organization: Whistle Communications X-Mailer: Mozilla 3.01Gold (Win95; I) MIME-Version: 1.0 To: John Polstra CC: obrien@FreeBSD.ORG, freebsd-ports@FreeBSD.ORG Subject: Re: gcc/g++ 2.8.1 port maintainers/modifiers References: <199807070245.TAA01057@austin.polstra.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-ports@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org John Polstra wrote: > > > > vashon$ cat test.cc > > > > #include > > > > vashon$ gcc28 -c -H test.cc > > > > /usr/local/lib/gcc-lib/i386-unknown-freebsd3.0/2.8.1/include/typeinfo > > > > /usr/local/lib/gcc-lib/i386-unknown-freebsd3.0/2.8.1/include/exception Ah. Running it directly, instead of in a Makefile... Which of course is exactly the wrong way to try and find this problem, but it gave me the clue I needed. The brain damage is in bsd.prog.mk: ] .if defined(DESTDIR) ] CFLAGS+= -I${DESTDIR}/usr/include ] CXXFLAGS+= -I${DESTDIR}/usr/include/g++ ] .end Obviously, I have DESTDIR defined (in fact, it is required). The bug is that the DESTDIR is examined, incorrectly, for include path information. This is because there is no seperation between the idea of installed binaries vs. installed build environment components. Therefore, the includes are redirected into the install environment, instead of the build environment. Of course, bsd.lib.mk is brain-damaged the same way, as is the bsd.libnames.mk, technically. > > In any case, it shouldn't be in the top level include directory, and > > the g++ includes the one in /usr/include in preference to that one, > > even if it were being put in the right place (ie: in include instead > > of, minimally, in include/g++/typeinfo). > > I can't parse that. Please, don't try to explain it to me until > you've understood the rest of this mail. The include directory the ,mk files force is not dependent upon which gcc/g++ is being used; it's invariant. > Did you read the output from "gcc28 -H" that I sent in my last mail? Yes. It's not what I got from a build in a Makefile (see above for explanation). > > The port is broken... > > Whatever breakage you've demonstrated to this point is not in the > port, it's in your installation, or your methodology, or your > assumptions. Actually, it's in the port's inability to affect the DESTDIR redefinition of the include path based on whether the ports compiler or the default compiler is being used. This is either a bug in the port, or a bug in the bsd.*.mk files. Thanks for the help in tracking this down; now if we could only get it fixed in -current... -- Terry Lambert -- Whistle Communications, Inc. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-ports" in the body of the message