ich möchte eine "shared library" erzeugen, die man auch direkt ausführen
kann. Ein Beispiel für eine solche Bibliothek ist die glibc:
# /lib/libc.so.6
GNU C Library stable release version 2.1.3, by Roland McGrath et al.
Copyright (C) 1992, 93, 94, 95, 96, 97, 98, 99 Free Software Foundation,
[...]
Ich habe also die Source-Files meiner Bibliothek mit dem gcc und der Option
-fPIC compiliert. Dabei ist auch eine Datei mit einer main() Funktion.
Alle Objektfiles werden dann zu der Bib zusammengewurschtelt:
gcc -shared -Wl,-soname,libtest.so.1.1 -o libtest.so.1.1 bla1.o bla2.o
Die Bibliothek kann ich problemlos zu anderen Programmen hinzulinken,
leider nur nicht ausführen, denn das führt zu einem "Segmentation fault".
Was mache ich falsch?
Gruß
Daniel Kabs
Wozu?
Was soll diese sinnfreie Spielerei? Kostet Platz und hat genau keinen
Nutzen. Leute, warum interessiert ihr euch nicht für
Programmierkonzepte, Grundlagen der Softwaretechnik, Algorithmen und
Datenstrukturen, sichere und saubere Software... es gibt so viele
sinnvolle Gebiete, aber die Leute beschäftigen sich mit solchen
schwachsinnigen Spielereien. Seufz.
Daniel, wenn du dich davon nicht abbringen läßt, dann LIES HALT DIE
GLIBC SOURCEN. Hint: bei ELF ist nicht main wichtig, sondern _start.
Und wenn du nicht mal das weißt, bist du von der Lösung noch einige
Jahrzehnte entfernt und solltest lieber bei den Grundlagen anfangen.
Felix
Felix von Leitner wrote:
>> ich möchte eine "shared library" erzeugen, die man auch direkt ausführen
>> kann.
>
> Wozu?
> Was soll diese sinnfreie Spielerei? Kostet Platz und hat genau keinen
> Nutzen.
Ich fand die Idee ganz nett, einige Funktionen der Lib direkt über die
Kommandozeile aufrufen zu können, ohne ein eigenes, kleines Programm
kompilieren zu müssen. Weiterhin besteht die Möglichkeit, daß mehrere
Soft-/Hardlinks auf das Binary der Bibliothek zeigen. Die Lib wird den
Namen des aufrufenden Programms auswerten und jeweils unterschiedliche
Funktionen ausführen. Und natürlich kann die Bibliothek - wie bisher -
dynamisch in andere Programme eingebunden werden.
Es gab etwas Ähnliches bei einer Schmalspur-Shell, die aus einem
großen Hauptprogramm und vielen Links darauf bestand.
> Leute, warum interessiert ihr euch nicht für
> Programmierkonzepte, Grundlagen der Softwaretechnik, Algorithmen und
> Datenstrukturen, sichere und saubere Software... es gibt so viele
> sinnvolle Gebiete, aber die Leute beschäftigen sich mit solchen
> schwachsinnigen Spielereien. Seufz.
Hei, ich interessiere mich dafür, aber manchmal hat man nicht die
Zeit für eine vollständige Konzeptionierung oder die Spezifikationen
ändern sich während der Implementierung. Was spricht denn gegen mein
Konzept?
> Daniel, wenn du dich davon nicht abbringen läßt, dann LIES HALT DIE
> GLIBC SOURCEN. Hint: bei ELF ist nicht main wichtig, sondern _start.
> Und wenn du nicht mal das weißt, bist du von der Lösung noch einige
> Jahrzehnte entfernt und solltest lieber bei den Grundlagen anfangen.
Danke für den Tip, aber die glibc Sourcen sind mir etwas zu länglich :-)
Ich werde in Richtung _start weiterforschen. Der Aufbau von ELF gehört
meiner Meinung nicht zu den Grundlagen, die ein Programmierer unbedingt
benötigt, aber vielleicht muß ich mich für meine Anwendung doch einlesen.
Habe folgendes gefunden:
ftp://tsx-11.mit.edu/pub/linux/packages/GCC/elf.ps.gz
Gruß
Daniel Kabs
> Habe folgendes gefunden:
> ftp://tsx-11.mit.edu/pub/linux/packages/GCC/elf.ps.gz
Mh, ELF ist vielleicht nicht der richtige Ansatzpunkt, denn es ist ja
nur der Behälter für die binären Objekte. Ich schaue lieber mal im Umfeld
von gcc und ld, denn die beiden erzeugen bzw. lesen die Binaries
schließlich.
Gruß
Daniel