Hallo,
ich habe ein kleines Programm (Konsolenanwendung) unter Cygwin
geschrieben. Cygwin deshalb, damit es unter Windows wie auch Linux
laufen kann.
Ich kann es auf beiden Plattformen kompilieren und starten.
Unter Linux gibt es allerdings ein Problem.
Kompiliere ich es unter einem SUSE-Linux 11.2 System, dann kann ich es
dort auch starten. Kopiere ich jetzt dieses Binary auf ein SUSE-Linux
10.0 System, dann bekomme ich beim Starten die Fehlermeldung:
1
./mymon: /lib/tls/libc.so.6: version `GLIBC_2.7' not found (required by ./mymon)
Wie löse ich das am besten? Es muss doch möglich sein, das Binary so zu
erstellen, dass es auf jedenfall in unterschiedlichen
Distributionen/Versionen läuft. Muss die GLIBC statisch dazugelinkt
werden? Wenn ja, wie mache ich das?
Oder muss ich die GLIBC mitliefern und in das Verzeichnis legen, wo auch
das Binary liegt?
Beide Lösungen finde ich unschön. Vielleicht kann mir jemand einen Tip
geben?
Vielen Dank.
Nachtrag:
Wenn ich die Anwendung testweise unter SUSE Linux 10.0 kompiliere, dann
kann ich es unter beiden Systemen laufen lassen, also auch auf dem SUSE
Linux 11.2.
Aber mein Entwicklungsrechner ist nunmal mit SUS Linux 11.2 ausgestattet
und dort möchte ich das kompatibel erstellen, wenn das möglich ist.
"Oder muss ich die GLIBC mitliefern und in das Verzeichnis legen, wo
auch
das Binary liegt?"
Das geht wirklich, indem Du LD_LIBRARY_PATH auf deine Privat-GLIBC setzt
und aus einem Wrapper dein Executable als Argument des dynamischen
Linkers aufrufst. Frisst aber Speicher und ist haesslich die Methode.
faustian schrieb:> Das geht wirklich, indem Du LD_LIBRARY_PATH auf deine Privat-GLIBC setzt> und aus einem Wrapper dein Executable als Argument des dynamischen> Linkers aufrufst. Frisst aber Speicher und ist haesslich die Methode.
Ufff. Bin absoluter Linux-Beginner. Kannst du das ein wenig
ausschmücken? ;-)
Was für einen Wrapper? Den LD_LIBRARY_PATH verbiegen klingt ziemlich
unschön. Ich weiss im Moment auch garnicht, wofür dieser gut ist. Ist
das der Pfad wo der GCC-Linker seine Libs sucht?
Und gibt es keine saubere Lösung?
Danke dir.
So ich hab mal Google angeworfen. Nun ist mir etwas klarer geworden, was
du mit dem Wrapper meinst. Mit solch einem Wrapper wäre das aber eine
Lösung, die den Rest des Systems nicht weiter beeinflußt, wenn ich das
richtig verstanden habe.
Die bevorzugte Methode wäre es wohl, das gesamte Projekt mit den Sourcen
weiterzugeben und dann auf dem Zielsystem ein Make zu machen?
Das würde ich allerdings nicht so gerne tun. Das ist ein Tool für die
Hardwarekollegen hier und die können noch weniger als ich auf einem
Linuxsystem kompileren ;-)
Darum bevorzuge ich eine Lösung, nur das Binary zu kopieren. Nagut,
vielleicht noch einen Wrapper.
Gibt es sonst noch Lösungen?
faustian schrieb:> "Oder muss ich die GLIBC mitliefern und in das Verzeichnis legen, wo> auch das Binary liegt?">> Das geht wirklich, indem Du LD_LIBRARY_PATH auf deine Privat-GLIBC> setzt und aus einem Wrapper dein Executable als Argument des> dynamischen Linkers aufrufst.
Das ist bei der glibc evtl. nicht ausreichend. Es kann sein, daß die
ld-linux.so nicht dazu paßt. Und dann muß man noch mehr tricksen,
damit's geht. Unter anderem muß man die ld-linux.so auch noch dazupacken
und diese ausführen (ja, die kann man tatsächlich ausführen wie ein
Programm). Ich hab auf die Weise mal einen mplayer eines kubuntu-Systems
komplett mit sämtlichen benötigten Libs auf ein Suse-System kopiert und
da ausgeführt.
Beginner schrieb:> Den LD_LIBRARY_PATH verbiegen klingt ziemlich unschön. Ich weiss im> Moment auch garnicht, wofür dieser gut ist.
Wie kommst du dann darauf, daß das unschön ist? "Verbiegen" muß man da
eigentlich nichts, sondern halt im Wrapper-Skript anlegen.
> Ist das der Pfad wo der GCC-Linker seine Libs sucht?
Das ist nicht direkt "der GCC-Linker", aber ja. Da ist der Pfad, wo er
sie zusätzlich zu den fest eingetragenen Verzeichnissen (siehe
ld.so.conf) sucht.
@Rolf magnus:
Ich sagte ja nicht welcher dynamische Linker :) Wobei es in der Tat gut
ist dass Du nochmal klargestellt hast dass dieser effektiv Teil der libc
und nicht des gcc ist.
Unschoen ist eine Privatlibc aus einigen Gruenden. Du paketierst alle
Sicherheitsluecken mit, verbrauchst einiges mehr an RAM, und kannst dir
frueher oder spaeter zB mit libnss-Erweiterungen interessanten Zores
einhandeln... Auch eine statische Libc wird dir solche Probleme bringen.
Am besten baut der OP sich ein Buildsystem, wo er eine reife und
konservativ eingerichtete Distribution installiert.
Hallo,
danke für die vielen Tips. Ein Buildsystem wäre sicher die beste der
Lösungen. Denke ich auch. Weiß nur grad nicht, wie ich das von NULL auf
anfange. Mach sonst nichts oder fast nichts unter Linux.
Hat jemand einen Link auf ein Howto?
Allerdings sollte das auch nur "mach mal eben" Projekt sein ;-)
Das statische Linken nur mit der GLIBC ist wohl auch nicht die Lösung
wie ich jetzt verstanden habe. Man muss dann wohl alle benötigten Libs
dazulinken. Es gibt doch ein Tool, mit dem man herausbekommt, was alles
für Libs gebraucht werden.... fragend in die Runde blicke ;-)
Aber wahrscheinlich ist das Binary dann einige MB gross :-(
Ist auch hässlich und evtl. nicht die Lösung für alle Fälle.
Wenn der Aufwand für das Buildsystem nicht zu groß ist, dann werde ich
wohl das wohl doch machen. Für Tips bin ich dankbar.
"Es gibt doch ein Tool, mit dem man herausbekommt, was alles
für Libs gebraucht werden"
Bei einem dynamischen gelunkenen Binary sagt dir ldd(1) was da immer
jedesmal in den Kuchen geruehrt wird, und damit auch was du wo
reinlinken musst....
Eine eigene Frage?
Dieser Thread ist über 16 Jahre alt.
Stell sie in einem eigenen Thread – dort lesen mehr Leute mit, und sie wird öfter und schneller beantwortet.