Universallösung(TM): Xdialog, kdialog, oder was?
Jan 'RedBully' Seiffert
redbully at cc.hs-owl.de
Tue Nov 25 19:14:39 CET 2008
Sebastian Lisken wrote:
> Hallo. Nachdem Ralf mir die Antwort von Jan weitergeleitet hat, habe ich mich
> vorübergehend auf eurer Liste angemeldet.
>
Willkommen!
> Das Projekt, um das es geht, ist die nächste Version des PrivacyDongle des
> FoeBuD (http://www.foebud.org/privacydongle). Der Dongle soll auf Windows,
> Mac OS X und Linux laufen.
Aha.
> Das habe ich auch erreicht. Zu meinem Hintergrund: Ich entwickele schon lange
> Software und habe nach Anfängen in der Schule mit C unter Unix viele
> Erfahrungen gesammelt, aber nie GUIs programmiert. Seit mehreren Jahren
> arbeite ich meistens in Java und mit Web-Programmierung, also wieder ohne
> "von Grund auf" entwickelte GUIs.
>
> Das fragliche Programm ist nur das Startprogramm, gestartet wird ein Firefox
> mit einem bestimmten Profil, das u.a. Tor enthält. Das Startprogramm soll in
> der Lage sein, den Firefox und das Tor-Binary zu aktualisieren.
OK
> Dafür sind die Dialogboxen da.
Hmmmm
> Ich brauche nur zwei ganz grundlegende, das Äquivalent zu alert und confirm
> in JavaScript - also eine mit Text und OK-Knopf und eine mit zusätzlich einem
> Cancel-Knopf und der Rückmeldung, welcher Knopf gedrückt wurde.
Vergiss mal grad Dialogboxen, du brauchst allgemein Userinput.
> Und das Ganze richtet sich an "unbedarfte" User und soll deshalb Dialoge
> benutzen, d.h. die xterm-Lösung wäre sehr unschön (obwohl ich auch schon
> selbst daran gedacht hatte).
>
Nunja, was spricht wirklich dagegen? Wenn ein User schon Linux hat, warum soll
das als Fallback nicht gehen? Erst versuchen das mit GUI zu machen, wenn das
nicht geht ein XTerm mit dialog-App starten? Hast du dir mal unter Knoppix die
"Helper" aus dem "Startmenu" angesehen (um Wifi einzurichten, Terminalserver,
etc.)? Einige sind mit GUI, sorgen aber warsch. dafuer, dass alle Dependencies
da sind, einige oeffnen ein Xterm mit Eingaben.
Sind die "unbenutzbar" aus User-sicht?
> Deshalb trifft die folgende Bemerkung ...
>
>> Nein, im Ernst: Entweder das Projekt macht Bunt&Grafik, dann nimm das
>> Toolkit welches das Projekt benutzt, oder lass es. Punkt.
>
> ... nicht ganz auf meine Situation zu, würde ich sagen. Ich habe per se kein
> Toolkit.
>
Doch, hast du:
Ohne Toolkit und X und foo und whatever wird dein Firefox nicht laufen. Es kann
sein das auf deinem PrivacyDongle wo der Firefox rumliegt (Ihr bringt ihn mit?
Oder kommt er vom Nutzer?) auch die benoetigten Libs rumliegen, oder das
versucht wird die vom System zu nutzen. Aber ein X werdet ihr wohl nicht mitbringen?
Du hast also schon Abhaengigkeiten. Die sind entweder da, oder du kannst dem
User gleich einen Fehler zeigen (der den unbedarften User aus der Bahn werfen
wird), das da was fehlt.
Unter Unixioden ein Binary-Only zu verteilen ohne ein README.1ST ist ...
moeglich, aber egal wie nix fuer unbedarfte. Punkt.
Das ist ein Kulturelles Problem. Seit Win und Mac ist es usus so ein Setup.exe
oder Programm.dmg zu haben, einmal klicken, nicht nachdenken.
Gibt es so ohne "grosse Schmerzen" nicht fuer Unixoide. Moegliche Loesungen
grenzen das immer weiter fuer ein Unixoides ein, bis hin fuer eine Distribution,
in Binaerpacketen sogar zu einer Version ("Runs with RHEL 4.5"). Das es
vielleicht auch wo anders geht ist moeglich, aber nicht garantiert (aka.
ueberfordert den unbedarften User), will man sogar nicht ("This is not RHEL,
installation aborted"), koennte ja Support bedeuten.
>> Aber da das ja nicht hip ist:
>> http://www.math.msu.su/~vvb/2course/Borisenko/CppProjects/GWindow/xintro.html
>>
>>
>
> Würde das mir zu einigermaßen "hübschen" Boxen verhelfen?
Bei weitem, nein.
X kann nur zeichnen, es kennt keine GUI-Elemente. Wir sind da so in der Liga
"Zeichne Linie, setze Hintergrund, packe (ungepacktes) Bitmap auf Monitor".
Fuer "mehr" sind die Toolkits da, und die koennen "fehlen" (oder einfach nicht
dein gewuenschtes da sein). Um keine Abhaengigkeit auf ein Toolkit aufzubauen
kann man aber X direkt ansprechen um ein "bischen" was auf den Schirm zu kriegen.
Wie schoen das ist kommt halt drauf an wie viel Code man darein investiert. Man
schreibt quasi sein eigenes Minimaltoolkit das nur das minimalsten Sachen kann:
Fenster oeffnen, Text anzeigen, Knoepfe anzeigen, Knoepfe auswerten. Das ganze
gleich in ein Programm gegossen was du von der CLI steuern kannst.
> Ich stelle mir vor, daß das Programm auf einem Linux läuft, auf dem auch ein
> graphischer Web-Browser eingesetzt wird. Aber ich weiß natürlich nicht, was
> für eine Fensteroberfläche auf dem System installiert ist.
>
Darum gegen pures X arbeiten, nur _schoen_ ist was anderes. Oder irgendwie mit
dem Webbrowser (und seinen Libs) arbeiten, den du ja eh brauchst.
>> Irgendwas auf den Bildschirm kleistern sollte in 200 Zeilen abgefruehstuckt
>> sein.
>>
>> Oder du must mal genauer beschreiben, was dieses Projekt machen soll.
>
> Es geht wirklich nur um diese beiden Typen von Dialogen. Zu realisieren als
> C++-Funktionen void alert(char*) und int confirm(char*).
>
Als C++?
Ah, nein, <Jedi-Power> Du *willst* kein C++ verweden </Jedi-Power>
Zumindest nicht fuer binary only.
>> Ja, er wollte eine Dialogbox. Was erwartest er denn? Windows und OSX
>> schummeln, da ist das ja auch schon alles gestartet.
>
> Laßt uns bitte nicht in eine OS-Diskussion und eine Verteidigungshaltung in
> Bezug auf die Komplexität der Situation gehen. Ich bin mit Windows und Linux
> grundsätzlich recht gut vertraut. Es geht nur um die Schwierigkeiten eines
> Programmierers, diese Dialogboxen herzustellen, ohne Wertung.
Es ist ein Unterschied in der Kultur der Plattformen.
Windows und MacX stellen eine Plattform dar, mit vielen APIs oft fuer alle
moeglichen und unmoeglichen Anwendungsfaelle. Diese Plattform wird _nicht_ an
einem "Runden Tisch" gemacht, und ist meist kaum bis garnicht standartisiert,
denoch kann ich sagen:
"braucht WinXP" und ich kann lustig WinRPC calls machen, DirectX benutzen, den
IE zum HTML rendern einbinden/zum aus dem Web herunter laden benutzen, XML
parsen, ODBC Datenbankabfragen machen, OLE Objekte einbinden, die Registry zum
speichern meiner Einstellungen benutzen, whatever.
Der Umfang wird diktiert, die Optionen sind begrenzt. (Denoch oft schon zu
vielfaeltig)
Eine Unix Plattform, nun durch POSIX definiert (und standartisiert), gibt es so
nicht (mehr). Alle sind POSIX Kompatibel. Und POSIX enthaelt viel (selbst wie
sich deine Shell verhaelt, dein make, welche optionen dein Compiler mindestens
kennen muss), aber es ist ein Bruchteil dessen, was ein Windows/MacX ausmacht.
HTML/XML? Wasn das?
HTTP/FTP? Mach dir nen Socket auf!
Config? Ja, sowas legen wir unter /etc ab. Wie? Sieh zu.
Datenbanken? gehoert BerkleyDB irgendwie zu POSIX? k.a.
Es ist das was Unix ausmacht, man kann diese Komponenten waehlen, austauschen
wenn sie nicht gehen, oder weglassen wenn man sie nicht braucht, das mag ich,
grade auch fuer Serverumgebungen.
Denoch vermisse ich manchmal die "Einfachheit" das es "da ist", was dann da ist
und es wohl keiner deinstalliert hat wenn man einiges davon brauchen koennte,
keiner mekert das man es braucht.
Man kann Platformen wie Windows/MacX sogar schnell POSIX beibringen (Ja, es gibt
von MS den POSIX-Layer fuer den NT-Kernel, Interix schimpft sich das AFAIK,
natuerlich an den wichtigen Stellen schoen inkompatibel gehalten damit eine
Portierung eines groesseren Unix-Programms gleich ein rewrite in WIN32 in
betracht zieht...)
Aber eine "reichhaltige Plattform" aus einem POSIX-Kompatiblem OS zu machen, ist
schwer, teilweise auch weil man in der jetzigen Position selten eine Technik
"durchdruecken" kann (Ob sie schlecht/gut/lahm/genial/whatever ist, ist egal,
Hauptsache sie ist die kanonische Loesung).
> Ich habe mir für Windows mingw32 installiert und ein bißchen Code aus dem
> Netz genommen und war sehr zufrieden, daß ich damit recht "normal" aussehende
> Boxen mit sehr wenig Aufwand bekam. Mir ist durchaus klar, daß unter Windows
> soviel einfacher ist.
Klar, ein Aufruf zu MsgBox, bumm Fertig, und das wird immer da sein. (oder
jemand hat GDI aus Windows entfernt, nicht unmoeglich (Xbox), aber unwarscheinlich)
> Aber ich kann den Overhead von mehreren gestarteten KDE-Prozessen oder
> beispielsweise einer zu startenden kompletten Java-VM nicht für dieses kleine
> Startprogramm vertreten.
Tja, willkommen im Club. Ich moechte aus einem Programm gaaaanz selten eine HTTP
Anfrage machen. Dafuer dem User curl mit 2 Mb und allen Zusatzlibs (kerberos,
ldap) aufs Auge druecken? Oder selber coden und HTTP "nicht richtig" implementieren?
> Aus Sicht eines Programmierers ist es wesentlich günstiger, daß das OS auch
> das Bauen von Dialogen und Fenstern mitdefiniert, das seht ihr hoffentlich
> auch.
Kommt drauf an ;)
Wenn ich es brauche, ja, klar, schaff ran den Kram.
Wenn nicht, was soll ich damit? Bloat!!1!elf!
Selbst wenn es nur eine Loesung geben wuerde, so gaebe es (hoffentlich dannn
immer noch) die Moeglichkeit das sie nicht da ist.
"Das Leben ist kein Wunschkonzert"
Sicher nicht der "unbedarfte User"-Fall, aber z.B.: 2 von den 5 hier anwesenden
Linux-Kisten haben keinen Monitor. Eine hat nicht mal ne GraKa, die andere nutzt
ihren Grafikspeicher als swap. So what?
> Ich kenne aber auch die Geschichte von Unix und Linux - als ich unter Unix
> anfing, gab es noch kein X - und verstehe, warum die GUI unter Linux nicht
> zum eigentlichen OS gehört. Wie gesagt, lassen wir bitte die Wertung raus und
> konzentrieren uns auf Problemlösungen.
>
Ich moechte dir das zugrunde liegende Problem aufzeigen, den IMHO ist dein
Problem/Wunsch so 100% nicht zu loesen. Ich versuche da keine OS-Diskussion zu
starten, denoch komme ich nicht um eine Verteidigungshaltung "herum":
- Das Leute dieses Konzept doof finden, weil nichts konsistent ist, alles
voellig ueberholt ist, gut, hab ich (fast) kein Problem mit. (Anm.: nicht deine
Haltung, nur ein haeufiges gebrachtes Argument)
(Einschub: Das deshalb viele grade kleine Projekte/Produkte und Softwerker Linux
ablehnen ist schade, und aus der Position des (erheblich) kleineren Markanteils
nicht gut, wie angemerkt ich kann manches Argument verstehen, denoch, es ist "am
Anfang" erstmal ein mentaler Schritt, vieles stellt sich dann als non-Issue raus.)
- Das es sich deshalb trozdem bitte wie ein Windows zu benehmen hat, das geht
mir auf den Zwirn.
Und ja, dringend dem User eine Dialogbox um die Ohren hauen, weil er ja soooo
unbedarft ist, aber bitte ohne zusaetzliche Kosten, ist eben "non-Unix".
(Starte dein Linux mal mit "init=/bin/sh", dann weist du was zusaetzliche Kosten
sind, aber auch was dir an Funktionen fehlt.)
Ich versuchte dir klar zu machen, das du mit dem Kopf durch die Wand willst.
Ja, ich weiss selber das unbedarfte User oft "panisch" reagieren wenn der
Computer was "von ihnen will" was sie so noch nicht gesehen haben ("So ein
komisches Fenster mit BUCHSTABEN!!!!!" "Buchstaben? Aha..."), frag mich nicht
genau woran es liegt (Zu technische Texte?), ein Patentrezept hab ich auch nicht.
Waer es schoen die Situation zu verbessern? Sicher. Wie? ...
Dialogbox ist nett, aber fprintf und scanf tuhn auch. Dass das manchmal die
implementierung einer zusaetzlich moeglichen Dialogbox verhindert ("wir haben
doch schon was"), tja.
Wie gesagt, anzuerkennen das es (vielleicht) keine Dialogbox gibt ist Teil des
Weges zur Problemloesung ;)
>> Kein statisch gelinktes Binary. Vieleicht ein eigenes, das sich mit dem
>> X-Server verbindet fuer ein bischen Fenster anzeigen, aber kein statisch
>> gelinktes.
>
> Das ist für mich immer noch der zentrale Teil dieser Diskussion. Deshalb
> bitte ich hier um Gründe.
Kompatibilitaet.
Das ist ein schwieriges Thema und beide Seiten glauben, sie haben den "Stein der
Weisen".
Linke ich eine Bibliothek statisch, dann habe ich:
- sie immer dabei
- in der Version in der ich sie brauche (ABI & API, kompatibilitaet mit mir)
Was ich verhindere (verhindern will):
- Programm startet wegen fehlender Libs nicht.
- Ich bekomme die Lib nicht (in der Version) fuer mein System
- Programm macht was komisches nachdem die Lib vom System upgedated wurde.
Was ich dazu bekomme:
- Fuer Sicherheitsupdates bin ich zustaendig.
- Kompatibilitaetsprobleme mit dem Zielsystem.
=> Ooops.
Also loest statisches linken nicht wirklich das Problem.
Ich bin deshalb dafuer dem User zu sagen, was er tun soll.
Aber ich mute ihm damit wohl zuviel zu.
> Andre Landwehr schreibt "klassischer Fall von nicht verstanden" und hat
> natürlich recht, denn das ist für mich Neuland. Aber ich habe gesehen, daß
> Qt4 von vielen Cross-OS-Projekten als Grundlage genommen wird und bei einer
> kurzen Recherche gelesen, daß man damit auch statische Binaries herstellen
> kann.
Ja, kann.
Mal an einem Beispiel:
Eagle ist ein binary only Platinen-Layout Program, das es fuer Windows, Mac und
Linux gibt. Dank QT kein Ding. Fast.
Es benutzt AFAIK in der 4er Version QT 3. Statisch gelinkt:
$ ldd /opt/eagle-lin-ger-4.16/bin/eagle
linux-gate.so.1 => (0xffffe000)
libXext.so.6 => /usr/lib/libXext.so.6 (0xb7fc3000)
libX11.so.6 => /usr/lib/libX11.so.6 (0xb7e8c000)
libdl.so.2 => /lib/libdl.so.2 (0xb7e88000)
libm.so.6 => /lib/libm.so.6 (0xb7e62000)
libc.so.6 => /lib/libc.so.6 (0xb7d32000)
libXau.so.6 => /usr/lib/libXau.so.6 (0xb7d2e000)
libXdmcp.so.6 => /usr/lib/libXdmcp.so.6 (0xb7d27000)
/lib/ld-linux.so.2 (0xb800e000)
Dies hat den Vorteil das ausser den Minimalanforung (X11) nichts da sein muss.
Es kann auch nicht passieren das ich das "falsche" QT habe. Da zumindest der C++
schmontz statisch gelinkt ist, machen die C++-ABI Aenderungen kein Problem.
Und es laeuft nicht mit Compositing, und ich kann auch nichts dran aendern (wie
die gefixte und funktionierende QT3 Bibliothek meines Systems dahinlegen, ach
wuerde auch nicht gehen, ist ja C++).
Tolle Wurst.
> Auf dieser Grundlage erscheint mir dieser Lösungsansatz zur Zeit als der
> interessanteste.
>
Denoch bedarf es dabei "viel Uebung". Was linkt man rein, was nicht, wie
erreicht man das am besten mit welchen Linkoptionen.
Man will z.B. libXwhatever nicht statisch einlinken, damit man hier das richtige
Interface zum X-Server hat. Man will die libc nicht statisch einlinken und auf
einem moeglichst alten (aber nicht zu altem ;) System kompilieren etc.
>> Unter Unix kannst du nur von der libc&POSIX ausgehen. Alles andere ist
>> Optional, ergo muss man dem Benutzer komunizieren, was da sein muss, oder
>> eben die Packetverwaltung benutzen. Darum will man die ja haben/benutzen.
>
> Wie gesagt, es geht hier um ein kleines "Anhängsel" (ein vorgeschaltetes) für
> einen Start von Firefox,
Und wenn es in C++ geschrieben ist wird es statisch ein riesen Teil. Ausserdem
musst du aufpassen das ALLE C++-Teile enthalten sind, es darf nichts mehr die
System libstdc++ ziehen.
> dafür kann ich dem Nutzer auf keinen Fall abverlangen, daß er Dependencies
> überprüft und seine Paketverwaltung anwirft.
>
Tja, du wirst nicht drumrum kommen...
>
> Eine Frage zum Verständnis: wie schafft es eigentlich Firefox, daß es als
> .tar.bz2 heruntergeladen, ausgepackt und gestartet werden kann? Ich weiß, daß
> die Distributoren ihre eigenen Versionen anbieten, die man über die
> Paketverwaltung installiert, aber die auf der Firefox-Seite angebotenen
> Versionen funktionieren wahrscheinlich auch auf sehr vielen
> Linux-Installationen?
Es ist auch teils statisch gelinkt, das macht es schoen gross (10Mb firefox-bin
alleine fuer 2.0.0.18). Weiterhin starten die nicht das Binary, sondern ein
Skript, das vorher den LD_LIBRARY_PATH auf das Verzeichniss setzt, wo man es
hininstalliert hat (fuer die mitgelieferten eigenen Bibliotheken), und dann
braucht es eben auch noch Systembibliotheken:
/var/tmp/firefox $ LD_LIBRARY_PATH=. ldd firefox-bin
linux-gate.so.1 => (0xffffe000)
^^^^^^^^^----- System
libmozjs.so => ./libmozjs.so (0xb7f2f000)
libxpcom.so => ./libxpcom.so (0xb7f2c000)
libxpcom_core.so => ./libxpcom_core.so (0xb7e81000)
libplds4.so => ./libplds4.so (0xb7e7e000)
libplc4.so => ./libplc4.so (0xb7e7a000)
libnspr4.so => ./libnspr4.so (0xb7e4c000)
^^^^^^^^^^---- bringt es mit
libpthread.so.0 => /lib/libpthread.so.0 (0xb7dff000)
libdl.so.2 => /lib/libdl.so.2 (0xb7dfb000)
libgtk-x11-2.0.so.0 => /usr/lib/libgtk-x11-2.0.so.0 (0xb7a97000)
libgdk-x11-2.0.so.0 => /usr/lib/libgdk-x11-2.0.so.0 (0xb7a13000)
libatk-1.0.so.0 => /usr/lib/libatk-1.0.so.0 (0xb79f3000)
libgdk_pixbuf-2.0.so.0 => /usr/lib/libgdk_pixbuf-2.0.so.0 (0xb79db000)
libpangoxft-1.0.so.0 => /usr/lib/libpangoxft-1.0.so.0 (0xb79d2000)
libpangox-1.0.so.0 => /usr/lib/libpangox-1.0.so.0 (0xb79c4000)
libpango-1.0.so.0 => /usr/lib/libpango-1.0.so.0 (0xb797a000)
libgobject-2.0.so.0 => /usr/lib/libgobject-2.0.so.0 (0xb7939000)
libgmodule-2.0.so.0 => /usr/lib/libgmodule-2.0.so.0 (0xb7933000)
libglib-2.0.so.0 => /usr/lib/libglib-2.0.so.0 (0xb7844000)
libX11.so.6 => /usr/lib/libX11.so.6 (0xb770d000)
libgthread-2.0.so.0 => /usr/lib/libgthread-2.0.so.0 (0xb7708000)
libm.so.6 => /lib/libm.so.6 (0xb76e2000)
^^^^^^^^^^----- vom System
libsmime3.so => ./libsmime3.so (0xb76c1000)
libssl3.so => ./libssl3.so (0xb769a000)
libnss3.so => ./libnss3.so (0xb7631000)
^^^^^^^^^^---- bringt es mit
libsoftokn3.so => ./libsoftokn3.so (0xb75e5000)
libXrender.so.1 => /usr/lib/libXrender.so.1 (0xb75da000)
libfontconfig.so.1 => /usr/lib/libfontconfig.so.1 (0xb75a4000)
libfreetype.so.6 => /usr/lib/libfreetype.so.6 (0xb74db000)
libXt.so.6 => /usr/lib/libXt.so.6 (0xb7472000)
libXft.so.2 => /usr/lib/libXft.so.2 (0xb7452000)
^^^^^^^^^^----- vom System
libxpcom_compat.so => ./libxpcom_compat.so (0xb743b000)
^^^^^^^^^^---- bringt es mit
libstdc++.so.5 => /usr/lib/gcc-lib/i686-pc-linux-gnu/3.3.6/libstdc++.so.5
(0xb737b000)
libgcc_s.so.1 => /usr/lib/gcc/i686-pc-linux-gnu/4.3.2/libgcc_s.so.1 (0xb736c000)
libc.so.6 => /lib/libc.so.6 (0xb723c000)
/lib/ld-linux.so.2 (0xb7fcb000)
libpangocairo-1.0.so.0 => /usr/lib/libpangocairo-1.0.so.0 (0xb7230000)
libXcomposite.so.1 => /usr/lib/libXcomposite.so.1 (0xb722c000)
libXdamage.so.1 => /usr/lib/libXdamage.so.1 (0xb7229000)
libXfixes.so.3 => /usr/lib/libXfixes.so.3 (0xb7223000)
libcairo.so.2 => /usr/lib/libcairo.so.2 (0xb717b000)
libXext.so.6 => /usr/lib/libXext.so.6 (0xb7167000)
libXinerama.so.1 => /usr/lib/libXinerama.so.1 (0xb7163000)
libXi.so.6 => /usr/lib/libXi.so.6 (0xb7159000)
libXrandr.so.2 => /usr/lib/libXrandr.so.2 (0xb7151000)
libXcursor.so.1 => /usr/lib/libXcursor.so.1 (0xb7143000)
libpangoft2-1.0.so.0 => /usr/lib/libpangoft2-1.0.so.0 (0xb70f8000)
libz.so.1 => /lib/libz.so.1 (0xb70e0000)
libXau.so.6 => /usr/lib/libXau.so.6 (0xb70dc000)
libXdmcp.so.6 => /usr/lib/libXdmcp.so.6 (0xb70d5000)
librt.so.1 => /lib/librt.so.1 (0xb70cc000)
libexpat.so.1 => /usr/lib/libexpat.so.1 (0xb709f000)
libSM.so.6 => /usr/lib/libSM.so.6 (0xb7094000)
libICE.so.6 => /usr/lib/libICE.so.6 (0xb7075000)
libdirectfb-0.9.so.25 => /usr/lib/libdirectfb-0.9.so.25 (0xb7004000)
libfusion-0.9.so.25 => /usr/lib/libfusion-0.9.so.25 (0xb6ffd000)
libdirect-0.9.so.25 => /usr/lib/libdirect-0.9.so.25 (0xb6feb000)
libpng12.so.0 => /usr/lib/libpng12.so.0 (0xb6fbe000)
libpixman-1.so.0 => /usr/lib/libpixman-1.so.0 (0xb6f74000)
libxml2.so.2 => /usr/lib/libxml2.so.2 (0xb6df2000)
^^^^^^^^^^----- vom System
... denn zum glueck hab ich noch die alte C++ lib
/var/tmp/firefox $ objdump -j .comment -s firefox-bin | head
firefox-bin: file format elf32-i386
Contents of section .comment:
00000 00474343 3a202847 4e552920 332e322e .GCC: (GNU) 3.2.
00010 33203230 30333035 30322028 52656420 3 20030502 (Red
00020 48617420 4c696e75 7820332e 322e332d Hat Linux 3.2.3-
00030 35342900 00474343 3a202847 4e552920 54)..GCC: (GNU)
00040 332e322e 33203230 30333035 30322028 3.2.3 20030502 (
00050 52656420 48617420 4c696e75 7820332e Red Hat Linux 3.
Jetzt kann man nur hoffen, das keine von den gezogenen Systemlibs C++ ist, sonst
knallts.
Wie gesagt, die kunst ist, das "richtige" statisch zu linken, dann andere
Bibliotheken dazu zu legen die man durch umbiegen des LD_LIBRARY_PATH bevorzugt
und "sinnvolles" eben einfach als vorhanden voraussetzt.
Und hier kommen wir dann in der Realitaet an. Wenn ein unbedarfter User keine
X-Libs hat, dann ist irgendwas maechtig schief gegangen.
Einem erfahrenem User helfen dann eher (die System-) Fehlermeldungen, ja, am
besten als Text. Eine Popupbox mit einen "GTK-Libs nicht gefunden" hilft _mir_
nicht, besonders wenn der richtige Fehler, um den unbedarten User nicht zu
erschrecken ("Ich mag Linux nicht, da sind beim starten immer so viele
Fehlermeldungen auf dem Bildschirm" ...), nach /dev/null umgeleitet wird.
Der unbedarfte User wird sich aber nicht mit den Feinheiten der libstdc++
rumschlagen wollen -> schon eher ein Problem.
Und wie man das Problem loest, das gtk nicht da ist auf einem KDE-only System,
tja, das weiss ich auch nicht. Das readme schickt einen auf die Runterlad-Seite,
dort gibt es auch kein "requirements" oder sowas, sondern nur irgendwo in der
Wissensdatenbank (Die nebenbei einen als erstes erklaert wie man Firefox besser
ueber die Packetverwaltung installiert ^^). Jupp, sieht so aus, das Gtk da sein
muss:
Firefox wird ohne die folgenden Bibliotheken oder Pakete nicht ausführbar sein:
* GTK+ 2.10 oder höher
* GLib 2.12 oder höher
* Pango 1.14 oder höher
* X.Org 1.0 oder höher
Da kann man nur davon ausgehen das selbst ein KDE-System einen
Distributions-Firefox hat und deshalb die libs doch rumliegen.
Man kann es einfach nicht auf jedem System zum laufen bringen, so das man
vielleicht als minimum sowas wie "Fedora 5 o.ae." angeben muss.
Und als konkrete Loesung:
Legt deine eigene version von xdialog mit auf den Stick. Das Programm nutzt auch
gtk, das muss also eh da sein. So gibts es auch schoene Boxen.
Wenn sich xdialog nicht starten laesst, versuch, irgendwie einen puren
Informationstext ueber den Fehler dem User naeher zu bringen (Es gab problem
foo: ... Versuchen sie dies, das, jenes), irgendwas wird ja auf dem System sein
(konqueror, links/lynx im xterm, groff mit xviewer, xterm mit printf, was einem
noch so einfaellt). Wenn das alles faehlschlaegt, hat der unbedarfte User Pech
(wie kommt er zu so einem System), andere werden sich dann mal den Output in der
Shell ansehen.
> Ich bin auch nur an solchen Installationen interessiert, weil ich eben so
> einen heruntergeladenen Firefox verwende.
>
Auf neueren Systemen wirst du damit "spass" haben (fehlende v5 C++-lib)
> Danke schonmal
>
> Sebastian
Gruss
Jan
--
Neulich bei Siemens: "Hast du die Maschinen geschmiert?" - "Und wenn,
würde ich es nicht zugeben."
More information about the Linux
mailing list