Date: Tue, 07 Jul 1998 13:15:36 -0700 From: Terry Lambert <terry@whistle.com> To: John Polstra <jdp@polstra.com> Cc: obrien@FreeBSD.ORG, freebsd-ports@FreeBSD.ORG Subject: Re: gcc/g++ 2.8.1 port maintainers/modifiers Message-ID: <35A281E8.FCE@whistle.com> References: <199807070245.TAA01057@austin.polstra.com>
next in thread | previous in thread | raw e-mail | index | archive | help
John Polstra wrote:
> > > > vashon$ cat test.cc
> > > > #include <typeinfo>
> > > > 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?35A281E8.FCE>