Hi again, Below is the response from the Debian gcc-3.0 maintainer regarding this -I/usr/include problem. He doesn't view it as a bug since gcc is doing what the documentation says it should (which I have to agree with, see gcc 3.0 docs on -I and -isystem flags). However, this new behavior definitely goes against previous expectations. I think as more rooters move to gcc 3.0 installed in /usr this will become more of an issue. For now, I am happy with the current work arounds since we haven't yet finished porting our own code to gcc 3.0. Thanks, -Brett. Daniel Jacobowitz writes: > On Sat, Jul 14, 2001 at 09:59:12AM -0400, Brett Viren wrote: > > Package: g++-3.0 > > Version: 3.0-4 > > > > Hello, > > > > This bug report may need to be redirected to a different package > > (cpp-3.0 or libstdc++3-dev). > > > > Adding "-I/usr/include" to the compile line of g++-3.0 can cause > > system headers in /usr/include to *not* be found. This is due to the > > use of #include_next inside /usr/include/g++-v3/bits headers. This > > directive causes the CPP to check for the file in any directories > > after the current one in the list. Explicitly adding -I/usr/include > > evidently removes it from the list of internal directories to check. > > Yes, that's right. It's not a bug, however. That's what -I is > documented to do; it moves a direcvtory to the head of the include > chain if it's already been specified. > > Don't do this. Any script which emits -I/usr/include or makefile that > assumes it is broken. > > -- > Daniel Jacobowitz Carnegie Mellon University > MontaVista Software Debian GNU/Linux Developer
This archive was generated by hypermail 2b29 : Tue Jan 01 2002 - 17:50:52 MET