PDA

Archiv verlassen und diese Seite im Standarddesign anzeigen : Kylix3: Wie "komplette" ausführbare Dateien erzeugen?


aths
2004-04-08, 15:47:07
Die ausführbare Datei ist stand alone offenbar nicht lauffähig. Er meckert:

/opt/kylix3/testprogramme/test1 # ./Project2
./Project2: relocation error: ./Project2: undefined symbol: initPAnsiStrings

Muss ich da noch was extra linken? Wenn ja, wie?

Crushinator
2004-04-08, 16:04:30
"/etc/ld.so.conf" um "/<woauchimmer/kylix3/bin" ergänzen, ldconfig aufrufen, fertig. Damit die Executable auch auf Maschinen ohne installiertem Kylix läuft, guxx0rst Du bitte hier (http://www.efg2.com/Lab/Library/Kylix/deployment.htm) unter "Deployment to Machine Without Kylix Installed" nach. Es müssen dafür naym1ich ein paar Libs auf dem Zielsystem existieren.

aths
2004-04-08, 16:06:48
Original geschrieben von crushinator
"/etc/ld.so.conf" um "/<woauchimmer/kylix3/bin" ergänzen, ldconfig aufrufen, fertig. Damit die Executable auch auf Maschinen ohne installiertem Kylix läuft, guxx0rst Du bitte hier (http://www.efg2.com/Lab/Library/Kylix/deployment.htm) unter "Deployment to Machine Without Kylix Installed" nach. Es müssen dafür naym1ich ein paar Libs auf dem Zielsystem existieren. Diese Libs lassen sich nicht in das Executable linken?

Crushinator
2004-04-08, 16:27:00
Nein, leider nicht von Borland vorgesehen, daß man diese "shared objects" statisch linkt. ;(

aths
2004-04-08, 16:43:23
Dann ist Kylix Dreck :(

Crushinator
2004-04-08, 17:50:42
Es gibt nunmal kein einheitliches Linux, deshalb kann man weder erwarten, daß die für CLX-Anwendungen benötigte QT-Bibliothek überall zu finden ist, womöglich auch noch vom Funktionsumfang/Verhalten kompatibel zur eigenen Anwendung, noch ist's zumutbar in jeder Executable die ca. 5 MB großen Bibliotheken von Borland mitzuschleppen, welche eine zur Anwendung garantiert kompatible QT-Umgebung erzeugen und damit u.A. auch unter GNOME laufen. Dann lieber die 5 MB einmal installieren und von allen eigenen Anwendungen nutzen.

Wie bereits angedeutet, ich find's auch schade, habe jedoch Verständnis dafür, daß es so ist.

aths
2004-04-15, 14:40:55
Original geschrieben von crushinator
Es gibt nunmal kein einheitliches Linux, deshalb kann man weder erwarten, daß die für CLX-Anwendungen benötigte QT-Bibliothek überall zu finden ist, womöglich auch noch vom Funktionsumfang/Verhalten kompatibel zur eigenen Anwendung, noch ist's zumutbar in jeder Executable die ca. 5 MB großen Bibliotheken von Borland mitzuschleppen, welche eine zur Anwendung garantiert kompatible QT-Umgebung erzeugen und damit u.A. auch unter GNOME laufen. Dann lieber die 5 MB einmal installieren und von allen eigenen Anwendungen nutzen.

Wie bereits angedeutet, ich find's auch schade, habe jedoch Verständnis dafür, daß es so ist. Meinetwegen kann das File auch 25 oder 50 MB groß sein, wenn es nur standalone lauffähig ist.

MadMan2k
2004-04-24, 15:52:29
Original geschrieben von crushinator
Es gibt nunmal kein einheitliches Linux, deshalb kann man weder erwarten, daß die für CLX-Anwendungen benötigte QT-Bibliothek überall zu finden ist, womöglich auch noch vom Funktionsumfang/Verhalten kompatibel zur eigenen Anwendung, noch ist's zumutbar in jeder Executable die ca. 5 MB großen Bibliotheken von Borland mitzuschleppen, welche eine zur Anwendung garantiert kompatible QT-Umgebung erzeugen und damit u.A. auch unter GNOME laufen. Dann lieber die 5 MB einmal installieren und von allen eigenen Anwendungen nutzen.

Wie bereits angedeutet, ich find's auch schade, habe jedoch Verständnis dafür, daß es so ist.
also kann man mit Kylix nur Qt Anwendungen erzeugen?
Ich bevorzuge nämlich GNOME und damit GTK2...

zeckensack
2004-04-24, 18:49:13
Kann man das nicht über entsprechende Abhängigkeiten lösen?
RPMs und andere, ähnliche Installationsmechanismen unterstützen doch sowas, oder?

Crushinator
2004-04-24, 23:17:15
Original geschrieben von MadMan2k
also kann man mit Kylix nur Qt Anwendungen erzeugen?
Ich bevorzuge nämlich GNOME und damit GTK2... Jein, man kann mit den von aths angemeckerten "shared objects" Anwendungen erzeugen, die auch laufen, wenn kein QT/KDE auf dem Ziel-System existiert. Diese "shared objects/libs" sorgen nämlich für die benötigte "Umgebung".

Gruß,
angetrunkener Crushi auf Gäb00rtstachsfayer vom Bäkannten, Hicks.

/edit:
@Zecki
Selbstverständlich geht's mit entsprechenden RPMs, wenn ich das aber richtig verstanden habe, würde aths "alles dafür geben" wenn er eine einzige Executable erzeugen könnte, welche keine Abhängigkeiten mehr bräuchte, weil sie all die benötigten libs statisch beinhalten würde. ;(