[Bug c/42300] New: Having LIBRARY_PATH set but with null contents, makes gcc read ./specs

[viriketo at gmail dot com]

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