[C][linux] shared libraries facoltative a runtime

[Duchamp]

Buongiorno a tutti; sto testando un po' la questione Linux e sono arrivato a capire quanto segue: se nel mio programma faccio uso di una certa libreria linkata in modo dinamico e poi passo questo programma ad un amico, lui dovrà naturalmente possedere la libreria per poter avviare il software.

A me però piacerebbe fare un passo indietro e valutare la presenza della libreria a runtime: il programma parte a prescindere, se la libreria esiste uso le funzionalità che offre, altrimenti disabilito le feature che la riguardano.

Secondo voi questo è possibile o bisogna per forza compilare da zero? Oppure creare due binari del programma, uno con le funzionalità della lib e uno senza?
Oppure distribuire, insieme ai binari, le librerie più esotiche che potrebbero non essere installate di default?

Vi ringrazio in anticipo per qualsiasi delucidazione vogliate darmi

[WarDuck]

Se non ricordo male c'è la funzione dlopen() che fa al caso tuo, dagli un'occhiata.

[Duchamp]

Originariamente inviato da WarDuck

Se non ricordo male c'è la funzione dlopen() che fa al caso tuo, dagli un'occhiata.

Ciao WarDuck, non conoscevo dlopen() ma ho già inutito qualche problema - correggimi se sbaglio: dovrei usare il suo handle interno per "chiamare" le funzioni presenti nella libreria e questo richiederebbe un grosso lavoro di riscrittura. Ancora peggio se la lib in questione è inclusa a sua volta da altre lib di "terze parti" su cui non ho controllo (oppure sì, ma ritoccando migliaia di linee di codice).

Però ci stiamo avvicinando! Non sarebbe carino indicare quali librerie usare? Magari non quelle in /usr/lib ma in una cartella che fornisco insieme al software? So che floola si comporta proprio così: fornisce insieme al binario una folder chiamata "floola libs". Insomma, come delle dll! Come si può ottenere tutto ciò?


EDIT: naturalmente questa sarebbe una soluzione un po' brute force: fornisco io, sin da subito, tutte le librerie necessarie

[marco.r]

Distribuire eseguibili binari in linux e' un calvario perche' non hai mai la garanzia che una persona abbia le librerie che servono.
e se ce le ha probabilmente sono di una versione differente
e se e' la stessa versione probabilmente sono state compilate con flag differenti.

Consiglio mio: se puoi compila staticamente le librerie, molto meno sbattimento.
Se la licenza crea problemi (e.g. e' LGPL) collega dinamicamente, distribuisci le librerie che ti servono e gioca di LD_LIBRARY_PATH

[Duchamp]

Originariamente inviato da marco.r

Distribuire eseguibili binari in linux e' un calvario perche' non hai mai la garanzia che una persona abbia le librerie che servono.
e se ce le ha probabilmente sono di una versione differente
e se e' la stessa versione probabilmente sono state compilate con flag differenti.

Consiglio mio: se puoi compila staticamente le librerie, molto meno sbattimento.
Se la licenza crea problemi (e.g. e' LGPL) collega dinamicamente, distribuisci le librerie che ti servono e gioca di LD_LIBRARY_PATH

Sono in piena via crucis con sta storia delle librerie
E ovviamente il 50% è in LGPL... la tua soluzione di settare LD_LIBRARY_PATH mi sembra molto realistica. Se fosse qualcosa di definibile in fase di compilazione sarebbe meraviglioso, evitando di angosciare il mio utente con script e file di sistema. E' possibile?

[marco.r]

Originariamente inviato da Duchamp

Sono in piena via crucis con sta storia delle librerie
E ovviamente il 50% è in LGPL... la tua soluzione di settare LD_LIBRARY_PATH mi sembra molto realistica. Se fosse qualcosa di definibile in fase di compilazione sarebbe meraviglioso, evitando di angosciare il mio utente con script e file di sistema. E' possibile?

Uhm, forse si' ma non ti conviene
Ti conviene piuttosto creare uno script che faccia le poche operazioni necessarie e lanci l'eseguibile vero e proprio.
Se nomini lo script col nome del programma e il tuo programma come "programma.bin" ad esempio, il tuo amico neanche si accorgera' che sta lanciando uno script e non il programma vero e proprio.
Per inciso, e' quello che fanno molti programmi commerciali sotto linux, e diversi programmi open source.

giusto per dare una idea, sulla mia macchina di lavoro:

# file /usr/bin/* | grep script | wc -l
595

# file /usr/bin/* | grep executable  | wc -l
1769

Un quarto dei binari della mia distribuzione sono in realta' script di qualche tipo.

[Duchamp]

Davvero interessante questa dritta, non avevo proprio considerato lo script che avvia il programma vero e proprio. Adesso mi studio la soluzione, nel frattempo ti ringrazio per il supporto!

[marco.r]

Un esempio tratto da google-chrome

#!/bin/bash
#
# Copyright (c) 2010 The Chromium Authors. All rights reserved.
# Use of this source code is governed by a BSD-style license that can be
# found in the LICENSE file.

# Let the wrapped binary know that it has been run through the wrapper.
export CHROME_WRAPPER="`readlink -f "$0"`"

HERE="`dirname "$CHROME_WRAPPER"`"

# We include some xdg utilities next to the binary, and we want to prefer them
# over the system versions because we know they work correctly for us. But if
# our path already exists, we leave it where it is, to allow overriding this.
# (Once distributions have picked up the updated xdg-mime, we can go back to
# appending $HERE rather than prepending.)
case ":$PATH:" in
  *:$HERE:*)
    # $PATH already contains $HERE, leave it where it is.
    ;;
  *)
    # Prepend $HERE to $PATH.
    export PATH="$HERE:$PATH"
    ;;
esac

# Always use our versions of ffmpeg libs.
# This also makes RPMs find the compatibly-named NSS3/NSPR symlinks.
if [[ -n "$LD_LIBRARY_PATH" ]]; then
  LD_LIBRARY_PATH="$HERE:$HERE/lib:$LD_LIBRARY_PATH"
else
  LD_LIBRARY_PATH="$HERE:$HERE/lib"
fi
export LD_LIBRARY_PATH

export CHROME_VERSION_EXTRA="stable"

# We don't want bug-buddy intercepting our crashes. http://crbug.com/24120
export GNOME_DISABLE_CRASH_DIALOG=SET_BY_GOOGLE_CHROME

exec -a "$0" "$HERE/chrome" "$@"

Guarda in particolare la sezione relativa a LD_LIBRARY_PATh