CIP: nur boost 1.35?

Community Software
21

Das ist was anderes, da /usr/local üblicherweise schon in den Standard-Suchpfaden vorkommt.

22

also falls es noch jemanden interessiert, mittels

export D_RUN_PATH=/local/boost-1.43/lib

vor dem “make”, hat’s geklappt. Allerdings muss man das ja jedes mal neu machen :confused:

Zu dem LD_LIBRARY_PATH hab ich im Internet gelesen, dass es “böse” ist und man es nicht machen soll. Kann jemand von euch was dazu sagen? (dementieren/bestätigen?)

23

Ist nicht böse. Soll man machen.

Ein Problem kann sein, dass der LIBRARY PATH bei jedem Binary, das man startet, angewendet wird. Also eben auch bei anderen Dingen, wo man ihn eigentlich nicht explizit will. Könnte irgendwann mal stören.

Eine leichte Lösung ist ein Shellscript “bla”:

#!/bin/sh
LD_LIBRARY_PATH=$LD_LIBRARY_PATH:<newpath> /<path-to-binary>/bla-bin $@

… also ein Wrapper, der den LIBRARY PATH nur im Kontext des Programmaufrufs anwendet. Anstelle von bla-bin ruft man einfach bla auf.

24

oder einfach mit -static linken, zumindest für boost geht des

25

Naja, LD_LIBRARY_PATH ist schon boese, auch in der Variante von Ford. Das Problem ist, dass alle Kindprozesse auch das Environment erben. D.h. jedes Programm / Plugin / etc. was aus dem fraglichen Programm heraus aufgerufen werden wird wird auch LD_LIBRARY_PATH benutzen. Damit koennte man gelegentlich noch leben, viele Software ruft einfach nichts anderes auf, und wenn man “nur mal schnell” was zusammenschrauben will passt das schon. Zumindest wenn keine Bibliotheken verwendet werden die inkompatibel sind wie beispielsweise Boost…

Wirklich problematisch ist aber der naechste Schritt, den sowohl viele Software-Hersteller ins Installationsskript schreiben, als auch viele Leute mal in die .bashrc: LD_LIBRARY_PATH global setzen, so ala LD_LIBRARY_PATH=/opt/TolleSoftware/lib:${LD_LIBRARY_PATH}. Das fuehrt dann dazu, dass alle Software die Bibliotheken zuallererst in /opt/TolleSoftware/lib sucht, unabhaengig davon obs eigentlich noetig ist oder nicht. Und natuerlich liefern viele Hersteller dann noch alte und gammelige Versionen eigentlich ueberall verfuegbarer Bibliotheken mit, zB libpng oder sowas, die dann Sicherheitsluecken haben die ploetzlich alle Programme betreffen. Und diese Sicherheitsluecken kriegt man dann evtl. auch nicht einfach so los, indem man mal die libpng in /usr/lib updated, weil die ja ueberraschenderweise nicht benutzt wird, was man nicht unbedingt merkt bevors zu spaet ist…

Fuer Solaris (in Linux gibts keine grossen Unterschiede) siehe auch http://linuxmafia.com/faq/Admin/ld-lib-path.html oder auch einfach mal “LD_LIBRARY_PATH considered harmful” googlen und die Schmerzen betrachten :slight_smile:

Und so schwer ist es nicht, mit -L/linktime/path -rpath=/runtime/path oder LD_RUN_PATH das Zeug richtig zu linken und allen Benutzern die Schmerzen zu ersparen… ld(1) ist da recht lesbar und hilfreich.

26

thumbs up

danke für den Hinweis - diese Vererbungsgeschichte war mir überhaupt nicht bewusst!

27 
#!/usr/bin/env zsh
# GPLv3+

LD_PATH='' # "colon-separated list of directories in which to search for ELF libraries at execution-time" (man 8 ld.so)

BINARY='' # If empty, this...
BINARY=${BINARY:-${0}.org} # ...defaults to ${0}.org

LDSO='' # If empty, this...
read -A SYSLD <<< ${(f)$(ldd '/usr/bin/env')[(r)*/lib/ld*]}
SYSLD=${SYSLD[1]}
LDSO=${LDSO:-${SYSLD}} # ...defaults to a reasonable guess.

if [[ -n "${LD_PATH}" ]]; then
        ${LDSO} --library-path "${LD_PATH}" "${BINARY}" ${@}
else
        print -- 'ERRPR: empty LD_PATH' >&2
        exit 1
fi
28

Was soll das bringen? LD_PATH bleibt immer leer, das macht immer exit 1. Und ld.so suchen war nicht der Punkt.