This is the mail archive of the gcc-bugs@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: egcs 1.1a on DEC alpha OSF/3.2, problem with include files


On 12 Sep , Alexandre Oliva wrote:
> kuball  <kuball@zedo.fuedo.de> writes:
> 
>> On 10 Sep , Alexandre Oliva wrote:
>>> Does string.h appear in the preprocessed output?  Is it read from
>>> the directory where you expect it to live?
> 
>> No :(. It's read from /usr/local/lib/g++-include. But this are old
>> include files belonging to gcc 2.7.
> 
> `make install' won't clean up the g++-include directory, because it
> might contain something useful.

OK

>> Well, I specified
>> 	--enable-version-specific-runtime-libs
>> when buildng egcs.
> 
> But include-files are not libraries, right? :-)

>From the configure documentation:
--enable-version-specific-runtime-libs -- Specify that runtime libraries
should be installed in the compiler specific subdirectory
(${libsubdir}) rahter than the usual places. In addition, libstdc++'s
include files will be installed in ${libsubdir}/include/g++ unless you
overruled it [...]. Using this option is particularly useful if you
intend to use several versions of egcs/gcc in parallel.

>> How come that the above directory is added to the default search
>> path?
> 
> I guess it is searched by default.  Run `g++ -E -v - < /dev/null' to
> check what the search path is.

Yes, but why is /usr/local/lib/g++-include in the default path?
IMHO when using the above option the configure script should treat all
other g++ include directories as containing potentially harmful stuff.

>> And how can I remove it from the default search path?
> 
> You may want to configure
> --with-gxx-include-dir=/usr/local/include/eg++-1.1 or
> --with-local-prefix=/usr/local/egcs or even with
> --prefix=/usr/local/egcs-1.1
> 
> I'm not sure which one will fix your problem, but one of them should
> do it, but each one will have different side-effects.  I myself prefer
> to install each package in a separate directory, so I'd use the last
> option.  However, this may not eliminate the possibility of having
> /usr/local/lib/g++-include installed in the search path :-(

Meanwhile I just renamed the directory with the old include files ;).


Martin Kuball




Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]