I think that a LIBRARY_PATH set, but without any contents (as done in shell
with LIBRARY_PATH= ) will make gcc read the specs file from the directory '.'.
Having no LIBRARY_PATH in the environment does not make gcc read ./specs.
For example. this can break the build of a cross-compiler with g++, because the
g++ is compiled with the build gcc after building the cross-gcc, which created
a 'specs' file in the current directory (build/gcc).
In this build, the built-in specs in the build gcc should be used, and not
those of the cross compiler (./specs).
This can be reproduced trying to make a g++ cross-compiler with the
LIBRARY_PATH environment variable set but with a null string content.
I could reproduce this with gcc 4.3.4 too, either a native or a cross compiler.
If it is a feature, I think the LIBRARY_PATH section in the gcc manual should
explain about this, because I would expect this behaviour only under
LIBRARY_PATH=.
--
Summary: Having LIBRARY_PATH set but with null contents, makes
gcc read ./specs
Product: gcc
Version: 4.4.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: viriketo at gmail dot com
GCC build triplet: x86_64-linux
GCC host triplet: x86_64-linux
GCC target triplet: x86_64-linux or any target for a cross-compiler
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42300
