Hi,

hab auf einem Fedora Core 2 Kylix installiert.
Leider kann ich Kylix nicht starten obwohl die Installation fehlerfrei von statten ging.

Infos: - Kylix wurde als User installiert
- ./startbcb wirft die Fehlermeldung, daß die Share Object Lib nicht gefunden wurde
- ./startdelphi wird nicht ausgeführt. Fehlermeldung gibt es keine.
- Installationsverzeichnis ist nicht das Default- Verzeichnis. (Will auch nicht das Home- Verzeichnis zugemüllt haben)

Ich vermute, daß ihm irgendwelche Lib- Pfade fehlen. Allerdings wäre es nett
gewesen, wenn ./startdelphi mir da ne Meldung gebracht hätte.

Jemand ne Idee, wo ich die Pfade einstellen kann?

//Edit: Hab mir auch schon mal die Suchergebnisse angesehen, aber die haben auch keine Lösung gebracht.
Ungünstig ist eben, daß ich so garkeine Fehlermeldung von ./startdelphi bekomme.

Die Fehlermeldungen werden in diesem Skript explizit in den Mülleimer umgeleitet!
Kommentier das mal aus und du hast die Info!

Ok, mach ich sobald ich wieder an dem Rechner bin.
Danke für den Hinweis.
Ist ja auch sehr sinnvoll das in /dev/null zu pipen.

Einerseits schon, andererseits käme da soviel Müll, dass da keiner was von hätte, wenn es nicht gefiltert wird. Das ist halt Unix-Stil, du kannst alles anpassen, aber du musst auch alles anpassen!

Bei mir kamen dann unter Suse 9.2 noch andere Probleme: Programme liefen nur aus der IDE, direkt ging erst nicht (Pfade nachtragen), Kernel 2.6 nicht erkannt (Kernel 2.4 vorgespiegelt). Die Details habe ich nicht im Kopf, wenn du noch was brauchst, melde dich. Ich muss das dann mal abends zusammensuchen.

Jo, danke. Gut zu wissen.

wdbee hat folgendes geschrieben:

Einerseits schon, andererseits käme da soviel Müll, dass da keiner was von hätte, wenn es nicht gefiltert wird.

Kommt drauf an, von Fehlermeldungen hat man idR immer was, ansonsten sollten bei sauberer Installation und sauberer Programmierung keine Meldungen kommen. Filtern von Fehlermeldungen macht man normalerweise nur, wenn man davon ausgeht, daß es Fehlermeldungen gibt, und man weiß, daß sie belanglos sind, z.B. Warnungen staht Fehler. Aber selbst Warnungen sollten normalerweise nicht auftreten.

wdbee hat folgendes geschrieben:

Bei mir kamen dann unter Suse 9.2 noch andere Probleme: Programme liefen unr aus der IDE, dirket ging erst nicht (Pfade nachtragen)

Der Workaround stellt ein potenzielles Sicherheitsrisiko dar, weil dann vom Admin nicht geprüfte Programme "versehentlich" gestartet werden können. Der ./Präfix erinnert wenigstens daran, das man hier explizit eine Datei im aktuellen Verzeichnis ausführt.

wdbee hat folgendes geschrieben:

Kernel 2.6 nicht erkannt (Kernel 2.4 vorgespiegelt).

Ja, das ist ein Problem von Kylix, nicht von Unix oder GNU/Linux.

@opfer.der.genauigkeit: Wenn du nicht nach ~ installiert hast, hast du dann auch die nötigen Ausführungs- und Leserechte als der User, unter dem du arbeitest? Schonmal probiert Kylix als su zu starten?

tommie-lie hat folgendes geschrieben:

wdbee hat folgendes geschrieben: Bei mir kamen dann unter Suse 9.2 noch andere Probleme: Programme liefen nur aus der IDE, direkt ging erst nicht (Pfade nachtragen) Der Workaround stellt ein potenzielles Sicherheitsrisiko dar, weil dann vom Admin nicht geprüfte Programme "versehentlich" gestartet werden können. Der ./Präfix erinnert wenigstens daran, das man hier explizit eine Datei im aktuellen Verzeichnis ausführt.

Wovon redest du hier?

PS: Die o.g. Probleme treten auf, egal ob du als user oder admin, im vorgesehenen Pfad oder sonstwohin installiert hast, und egal ob du als admin oder user arbeitest!
Das Problem ist, dass es nicht DAS Linux/Unix gibt, sondern verschiedene und dass die Kylix-Version älter ist, als die Betriebssysteme, auf denen es installiert werden soll.

wdbee hat folgendes geschrieben:

tommie-lie hat folgendes geschrieben: wdbee hat folgendes geschrieben: Bei mir kamen dann unter Suse 9.2 noch andere Probleme: Programme liefen nur aus der IDE, direkt ging erst nicht (Pfade nachtragen) Der Workaround stellt ein potenzielles Sicherheitsrisiko dar, weil dann vom Admin nicht geprüfte Programme "versehentlich" gestartet werden können. Der ./Präfix erinnert wenigstens daran, das man hier explizit eine Datei im aktuellen Verzeichnis ausführt. Wovon redest du hier?

Du meinst vermutlich den "Bug", daß "./" nicht in der PATH-Environmentvariable war, und man deswegen nicht uns Verzeichnis gehen konnte und einfach "Project1" aufrufen konnte, sondern "./Project1" benutzen musste, oder? Das ist kein Bug, it's a feature.
Wenn du einen anderen Fehler meintest, vergiss es

wdbee hat folgendes geschrieben:

Das Problem ist, dass es nicht DAS Linux/Unix gibt, sondern verschiedene und dass die Kylix-Version älter ist, als die Betriebssysteme, auf denen es installiert werden soll.

Das ist allerdings ein Problem, deswegen rate ich jedem von Kylix weg, es gibt mittlerweile zu viele Fallstricke.

Die IDE setzt intern Pfade zu Bibliotheken. Deshalb laufen z.B. die mitgelieferten Demoprogramme aus der IDE heraus. Aber wenn man die IDE schließt, laufen die gerade erstellten Programme nicht mehr (ohne die IDE). Trägt man die Pfade aber in das Login-Skript ein, klappt es. Das war da gemeint!