2010-03-09 11 views
2

Je suis assis dans un environnement sur lequel je n'ai aucun contrôle réel (ce n'est pas seulement moi, donc fondamentalement, je ne peux pas changer l'environnement ou ça a gagné ' t travail pour quelqu'un d'autre), la seule chose que je peux affecter est comment le binaire est construit.Ignorer LD_LIBRARY_PATH et coller avec la bibliothèque donnée par -rpath au moment du lien

Mon problème est, l'environnement spécifie un LD_LIBRARY_PATH contenant un libstdC++ qui n'est pas compatible avec le compilateur utilisé. J'ai essayé de le compiler statiquement, mais cela ne semble pas possible pour g ++ (la version 4.2.3 semble avoir été faite dans ce sens dans les versions ultérieures qui ne sont pas disponibles, -static-libstdC++ ou quelque chose comme ça).

Maintenant, je suis arrivé à utiliser rpath pour faire le nom du chemin absolu dans l'exécutable (cela fonctionnerait, toutes les machines sur lesquelles il est censé fonctionner sont identiques). Malheureusement, il semble que LD_LIBRARY_PATH a priorité sur rpath (la réinitialisation de LD_LIBRARY_PATH a confirmé qu'il est capable de trouver la bibliothèque, mais comme indiqué ci-dessus, LD_LIBRARY_PATH sera défini pour tout le monde, et je ne peux pas le changer).

Y a-t-il un moyen pour que rpath prenne le pas sur LD_LIBRARY_PATH, ou y a-t-il d'autres solutions possibles à mon problème? Notez que je parle de la liaison dynamique à l'exécution, je suis capable de contrôler la ligne de commande au moment de la compilation et de la liaison.

Merci.

Répondre

1

Lier contre libstdc++.a est certainement possible, mais difficile. Instructions here.

Je suis un peu sceptique de votre affirmation selon laquelle LD_LIBRARY_PATH a priorité sur le « cuit dans » DT_RPATH bien - au moins sur Linux et (je crois) Solaris, LD_LIBRARY_PATH est seulement regardé après DT_RPATH recherche a échoué.

+0

J'ai vu cet article, et 'truquer' un répertoire sans un fichier '.so' pourrait fonctionner. Je suis seulement capable de changer le compilateur et la ligne de commande (bien que je puisse changer le compilateur en script), mais je peux peut-être créer mon propre lib-répertoire. Je vais essayer. En ce qui concerne la deuxième partie, il s'agit d'un environnement Solaris, et le test que j'ai fait était le suivant: 'ldd binary' donne la bibliothèque du LD_LIBRARY_PATH, et' LD_LIBRARY_PATH = ldd binary' donne le binaire (non trivial). Je ne sais pas comment cela est mis en œuvre, je peux seulement vous dire ce que je vois. – falstro

+0

L'affirmation selon laquelle «LD_LIBRARY_PATH» de Solaris a la priorité sur «DT_RPATH» est * [absolument correct] (http://docs.oracle.com/cd/E19082-01/819-0690/chapter6-63352/index.html) * tant que le processus ne répond pas à la définition d'un [processus sécurisé] (http://docs.oracle.com/cd/E19683-01/816-1386/6m7qcobkt/index.html). – vladr

3

Peut-être que vous pouvez utiliser un wrapper shell qui modifie l'environnement pour ce programme?

#!/bin/sh 

LD_LIBRARY_PATH="/path/to/your/lib:${LD_LIBRARY_PATH}" 
export LD_LIBRARY_PATH 
exec /path/to/binary [email protected] 

Cela devrait surcharger le LD_LIBRARY_PATH avant l'exécution, puis remplacer l'emballage avec votre binaire via exec.

Cela aiderait-il?