Ich habe unter Kylix (Delphi-Umgebung) ein kleines Testprogramm erzeugt. Einfach eine Form mit 'nem Button. Im OnClick-Event verändere ich mit

die Caption der Form1. Lasse ich das Programm jetzt per F9 kompilieren und starten funktioniert das auch. Beende ich aber Kylix und versuche das Programm manuell zu starten (per Konsole, Nautilus, Konqueror nichts funktioniert) (das Kompilat befindet sich ja in meinem home-Verzeichnis), startet das Programm nicht. Wenn ich es aus der Konsole heraus starte, kriege ich folgende Fehlermeldung:

GNOME-Konsole hat folgendes geschrieben:

Project1: relocation error: Project1: undefined symbol: initPAnsiString

Kennt das jemand und weiß, wie man das abstellt?
Ich benutze Kylix 3 Open Edition (Downloadversion), Mandrake 9 mit Standardkernel (2.4.19-mdk9), XFree 4.2, GNOME 2.0 oder KDE 3.

Hi,

ich habe da eine Lösung für Dich. Habe ich aus einem anderen Forum. Zumindest geht es bei mir unter Suse 8.1 und Kylix 3 Open Edition.

Trage einfach die folgenden 2 Zeilen in die Datei .bashrc ein :
(diese Datei steht versteckt im Homeverzeichnis des Benutzers, für den Nutzer Root gibt es die Datei nicht.)



Sollte es nicht gleich funktionieren, mache mal eine Neuanmeldung des Benutzers.

tommie-lie hat folgendes geschrieben:

GNOME-Konsole hat folgendes geschrieben: Project1: relocation error: Project1: undefined symbol: initPAnsiString Kennt das jemand und weiß, wie man das abstellt?

Diese Fehlermeldung ist etwas unpassend. Was sie wirklich aussagt:
libborqt.so konnte nicht gefunden werden.

Hier ein paar hilfreiche Links:
kylixlibs.sourceforge.net
homepages.borland.co...Kylix/deployment.htm

sorry das ich jetzt erst antworte, aber bin unterwegs un Internet ist nicht so schnell.
Andys Links konnte ich mir noch nicht anschauen, aber bis11s Tip hat geholfen. Die .bashrc gibt's zumindest bei mir auch für den root.
Aber was ist, wenn ich Programme weitergeben will? Ich kann doch nicht vom User verlangen, jedesmal die bashrc zu editieren.
(Wenn das durch Andys Links beantwortet wird, ht es sich erledigt)

Hi,

ich habe das folgendermaßen gelöst.

Du musst die problematischen Dateien mitgeben.
Du kannst sie einfach ins selbe Verzeichnis geben wie das Executable und ein Startscript schreiben, dass den LD_LIBRARY_PATh setzt.


Das ganze habe ich z.B. in dem Programmverzeichniss unter dem Namen startlxcad gespeichert. Beim Aufruf des Scriptes wird erst der Pfad gesetzt und danach das Programm gestartet.
Wenn Du Dein Programm mit den Laufzeit-Packages zusammen kompilierst, dann brauchst Du auch nur die Library:
libborqt-6.9.0-qt2.3.so mitzugeben und in dein Programmverzeichnis
zu kopieren.

So ich hoffe ich konnte helfen.

Sven

Einen hab ich noch.

Mittels ldd programmname stellst Du fest welche dynamische Library's von Deinem Programm benötigt werden. Wenn Du nach dem obigen Verfahren verfährst, dann brauchst Du dem User nur mitzuteilen, daß diese Dateien auf dem Rechner vorhanden sein müssen. Gemäß Borland sollte diese bei einer Linux-Standard-Installation immer da sein.

Sven

Jo, Andys zweiter Link besagt in etwa das gleiche.
Hat mir auch sehr geholfen.Schade eigentlich, daß Kylix den Vorteil von Delphi (keine Runtimes) nicht hat. Vorraussetzung der glibc und KDE hätten es auch gemacht, denk' ich mal, aber scheint dann wohl zur jetzigen Version nicht anders zu gehen.
Trotzdem danke!

tommie-lie hat folgendes geschrieben:

Schade eigentlich, daß Kylix den Vorteil von Delphi (keine Runtimes) nicht hat.

Den hat es sehr wohl. Nur nutzt die CLX die QT-Library und diese ist leider in C++ geschrieben, was ein direktes Verbinden mit der libqt.so verhindert. Aus diesem Grund wurde eine C-Schnittstellen SO geschrieben, die nun eben mit dem Programm mitgegeben werden muss. Ab Kylix 3 steht noch eine weitere Alternative zur Verfügung. Borland hat die QT-Library mit der C-Schnittstelle in die Datei libborqt.so zusammengeschnürrt, womit keine QT-Library mehr auf dem Zielsystem vorhanden sein muss, da sie mit dem Programm mitgeliefert wird/werden sollte.

Zitat:

Vorraussetzung der glibc und KDE hätten es auch gemacht

Und was werden Gnome, IceWM, WindowMaker, ... Anhänger denken?

sven hat folgendes geschrieben:

Mittels ldd programmname stellst Du fest welche dynamische Library's von Deinem Programm benötigt werden.

Das funktioniert nur eingeschränkt bei Programmen, die mit Kylix 3 kompiliert wurden. Dort wird zur Laufzeit entschieden, welche der beiden libs eingebunden werden soll, libborqt.so oder libqtintf.so. Aus diesem Grund sind diese Bibliotheken nicht über ldd ermittelbar.

@AndyB
Deine Aussage:

Zitat:

Das funktioniert nur eingeschränkt bei Programmen, die mit Kylix 3 kompiliert wurden. Dort wird zur Laufzeit entschieden, welche der beiden libs eingebunden werden soll, libborqt.so oder libqtintf.so

ist glaube ich nicht ganz korrekt.

Wenn ich Borland richtig verstanden habe, entscheidet sich das, je nachdem was vorhanden ist. Ist libborqt.so vorhanden so wird diese genommen, ansonsten libqtintf.so und libqt.so. Also entweder die eine, oder die beiden anderen.

Wenn man also sein Programm zusammen mit den Laufzeitpackages kompiliert, macht das Programm zwar etwas größer, ist aber immer noch kleiner als alle .so-Dateien mitzugeben, dann braucht man nur das Hauptprogramm und die libborqt (vereinigt libqt + libqtintf) auszuliefern.

Sven[/quote]

AndyB hat folgendes geschrieben:

Zitat: Vorraussetzung der glibc und KDE hätten es auch gemacht Und was werden Gnome, IceWM, WindowMaker, ... Anhänger denken?

Tja. Aber da hast du mich als GNOME-Anhänger natürlich auch getroffen. Aber die meisten "normalnutzer" installieren KDE eh mit, weil die Distributoren aus irgendeinem Grund alle KDE-Liebhaber sind und die so schön genannte "Standard Arbeitsplatz Installationen" basieren meist auf KOffice (oder mittlerwile auch OpenOffice.org) und KDE. Deswegen kann ich Qt-Anwendungen auch im Metacity laufen lassen, weil ich KDE immer noch installiert habe.

sven hat folgendes geschrieben:

Wenn ich Borland richtig verstanden habe, entscheidet sich das, je nachdem was vorhanden ist.

Nein, da bin ich euch nun wieder vorraus. Die Lektüre des Internets hat mir ans Tageslicht gebracht, daß es eine Systemvariable (irgendwas mit USE_LIBQT oder so) gibt. Ist diese gesetzt, benutzen Kylixprogramme die normale libqt und die libqtintf, ist sie nicht gesetzt verlangen Kylixprogramme diegebundlete libborqt.