According to g++ -print-search-dirs
my C++ compiler is searching for libraries in many directories, including ...
- /lib/../lib/:
- /usr/lib/../lib/:
- /lib/:
- /usr/lib/
Naively, /lib/../lib/
would appear to be the same directory as /lib/
— lib's parent will have a child named lib, "that man's father's son is my father's son's son" and all that. The same holds for /usr/lib/../lib/
and /usr/lib/
Is there some reason, perhaps having to do with symbolic links, that g++ ought to be configured to search both
/lib/../lib/
and/lib/
?If this is unnecessary redundancy, how would one go about fixing it?
If it matters, this was observed on an unmodified install of Ubuntu 9.04.
Edit: More information.
The results are from executing g++ -print-search-dirs
with no other switches, from a bash shell.
Neither LIBRARY_PATH nor LPATH are output from printenv
, and both echo $LPATH
and echo LIBRARY_PATH
return blank lines.
An attempt at an answer (which I gathered from a few minutes of looking at the
gcc.c
driver source and the Makefile environment).These paths are constructed in runtime from:
GCC_EXEC_PREFIX
)$LIBRARY_PATH
environment variable$LPATH
environment variable (which is treated like$LIBRARY_PATH
)-B
command-line switchThe last one (tooldir prefix) is usually defined to be a relative path: From gcc's
Makefile.in
However, these are for compiler-version specific paths. Your examples are likely affected by the environment variables that I've listed above (
LIBRARY_PATH
,LPATH
)Well, theoretically, if /lib was a symlink to /drive2/foo, then /lib/../lib would point to /drive2/lib if I'm not mistaken. Theoretically...
Edit: I just tested and it's not the case - it comes back to /lib. Hrm :(