g++ recherches /lib/../lib/, puis /lib/

selon g++ -print-search-dirs mon compilateur C++ recherche des bibliothèques dans de nombreux répertoires, y compris ...

  • /lib/../ lib/:
  • /usr/lib/../ lib/:
  • / lib/:
  • / usr / lib /

naïvement, /lib/../lib/ apparaîtrait être le même répertoire que /lib/ - le parent de lib aura un enfant nommé lib, "que le fils du père de l'homme est mon fils du père du fils" et tout ça. Il en va de même pour /usr/lib/../lib/ et /usr/lib/

  1. y a-t-il une raison, peut-être liée à des liens symboliques, pour que g++ soit configuré pour rechercher à la fois /lib/../lib/ et /lib/ ?

  2. S'il s'agit d'une redondance inutile, comment la réparer?

si cela importe, c'est observé sur une installation non modifiée de Ubuntu 9.04.

Edit: Plus d'informations.

les résultats sont de l'exécution g++ -print-search-dirs sans autres interrupteurs, à partir d'un shell bash.

ni LIBRARY_PATH ni LPATH ne sont sorties de printenv , et les deux lignes echo $LPATH et echo LIBRARY_PATH renvoient des lignes vierges.

3
demandé sur Thomas L Holaday 2009-06-13 13:15:12

2 réponses

une tentative de réponse (que j'ai recueillie à partir de quelques minutes en regardant la source du pilote gcc.c et l'environnement Makefile).

ces chemins sont construits en runtime à partir de:

  1. préfixe GCC exec (voir documentation GCC on GCC_EXEC_PREFIX )
  2. Le $LIBRARY_PATH variable d'environnement
  3. la variable d'environnement $LPATH (qui est traité comme $LIBRARY_PATH )
  4. toute valeur passée à -B commutateur de ligne de commande
  5. préfixes exécutables standards (tels que spécifiés pendant la période de compilation)
  6. préfixe Tooldir

le dernier (préfixe tooldir) est généralement défini comme un chemin relatif: De gcc Makefile.in 

# Directory in which the compiler finds libraries etc.
libsubdir = $(libdir)/gcc/$(target_noncanonical)/$(version)
# Directory in which the compiler finds executables
libexecsubdir = $(libexecdir)/gcc/$(target_noncanonical)/$(version)
# Used to produce a relative $(gcc_tooldir) in gcc.o
unlibsubdir = ../../..
....
# These go as compilation flags, so they define the tooldir base prefix
# as ../../../../, and the one of the library search prefixes as ../../../
# These get PREFIX appended, and then machine for which gcc is built
# i.e i484-linux-gnu, to get something like: 
# /usr/lib/gcc/i486-linux-gnu/4.2.3/../../../../i486-linux-gnu/lib/../lib/
DRIVER_DEFINES = \
-DSTANDARD_STARTFILE_PREFIX=\"$(unlibsubdir)/\" \
-DTOOLDIR_BASE_PREFIX=\"$(unlibsubdir)/../\" \

cependant, il s'agit de chemins spécifiques à la version du compilateur. Votre les exemples sont probablement affectés par les variables d'environnement que j'ai énumérées ci-dessus ( LIBRARY_PATH , LPATH )

3
répondu ASk 2009-06-13 10:09:34

en théorie, si / lib était un lien symbolique vers/drive2 / foo, alors / lib/../lib serait /usb2/lib si je ne me trompe pas. Théoriquement...

Edit: je viens de tester et ce n'est pas le cas - cela revient à /lib. Hrm: (

1
répondu Artem Russakovskii 2009-06-13 09:30:54