www.mikrocontroller.net

Forum: PC Hard- und Software Hilfe: Linux GCC Problem: GLIBC not found


Autor: Beginner (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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:
./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.

Autor: Beginner (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: faustian (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
"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.

Autor: Beginner (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Beginner (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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?

Autor: Mark Brandis (markbrandis)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Statisch linken müsste gehen. Kriegt man halt ein entsprechend größeres 
Binary.

http://gcc.gnu.org/onlinedocs/gcc/Link-Options.html

Option "-static"

Grad mal ausprobiert mit nem Hello World:
-rwxrwxr-x   1 user     user        11711 Jul 13 17:38 hello.exe
-rwxrwxr-x   1 user     user       932099 Jul 13 17:39 hello_static.exe

Autor: Rolf Magnus (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: faustian (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@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.

Autor: Beginner (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: faustian (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
"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....

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.