Universallösung(TM): Xdialog, kdialog, oder was?

[Jan 'RedBully' Seiffert]

Sebastian Lisken wrote:
[snip]
> Ein paar Antworten:
> 
[snip]
> und ob ein
> auszupackendes Firefox-Archiv in der "Installationswurzel" vorliegt (in
> einer späteren Version könnte es ihn auch direkt aus dem Netz holen,
> falls der User das bestätigt - an der Stelle habe ich mich auch schon
> gefragt, ob ich von curl oder wget ausgehen oder es mitliefern kann)

Hmmm, das ist auch mal wieder nicht einfach. Nimm wget. Leg das dabei.
Besorg dir von Debian die sources (das Programm ist upstream dead und wird nur
noch von den Debian Maintainern gepflegt).
Wenn ich bei mir schaue:
~ $ ldd `which wget`
        linux-gate.so.1 =>  (0xffffe000)
        libssl.so.0.9.8 => /usr/lib/libssl.so.0.9.8 (0xb7ffb000)
        libcrypto.so.0.9.8 => /usr/lib/libcrypto.so.0.9.8 (0xb7ea0000)
        libdl.so.2 => /lib/libdl.so.2 (0xb7e9c000)
        librt.so.1 => /lib/librt.so.1 (0xb7e93000)
        libc.so.6 => /lib/libc.so.6 (0xb7d63000)
        libgssapi_krb5.so.2 => /usr/lib/libgssapi_krb5.so.2 (0xb7d35000)
        libkrb5.so.3 => /usr/lib/libkrb5.so.3 (0xb7c9a000)
        libcom_err.so.2 => /lib/libcom_err.so.2 (0xb7c96000)
        libk5crypto.so.3 => /usr/lib/libk5crypto.so.3 (0xb7c6b000)
        libresolv.so.2 => /lib/libresolv.so.2 (0xb7c59000)
        /lib/ld-linux.so.2 (0xb8080000)
        libpthread.so.0 => /lib/libpthread.so.0 (0xb7c42000)
        libkrb5support.so.0 => /usr/lib/libkrb5support.so.0 (0xb7c38000)

Baue es ohne Kerberos-Unterstuezung, libssl/crypto vielleicht besser statisch
einlinken. libcom_err sollte auf jedem System vorhanden sein, aber ich weiss
nicht, wie es da mit der Kompatibilitaet aussieht. Rest dynamisch gelinkt lassen.

Aber siehe auch weiter unten.

> Jan:
>> Als C++?
>> Ah, nein, <Jedi-Power> Du *willst* kein C++ verweden </Jedi-Power>
>> Zumindest nicht fuer binary only.
> 
> Sorry, das verstehe ich jetzt nicht :-)

Nagut, mal etwas ausfuehrlicher:
C++, grade fuer riesen Anwendungen, ist sicher interresant und toll. Es ist aber
aus "Integrator"-Sicht (das was du grade versuchst) ein Alptraum. Und das kann
manchmal bis zum User durchschlagen (z.B. er kann die neuste Version von
whatever nicht auf seinem alten System installieren, bevor er nicht ein Major
Systemupdate macht, was moeglich waere, es aber eben einfach nicht gibt).

Deshalb fuer kleine Futzeltool gleich zu C++ zu greifen sollte vermieden werden.

Was macht das Kind so schlimm:
Zumindest auf Linux ist C++ einfach zu sehr ein moving Target (und das wo es
sich im Schneckentempo bewegt). Vielleicht kommt da in baldiger Zukunft wieder
etwas Ruhe rein, wobei ich das nicht glaube, da die naechste Standardversion
ansteht (wobei einige der letzten breakages in antizipation zu diesem stehen).

Mal am konkreten Beispiel:
mit gcc 3.4 gab es einem grossen ABI-break, das war vor 4 Jahren. Noetig war die
Aendrung da die gcc-Auguren festgestellt hatten, das sie mit der bisherigen ABI
nicht alle Exceptions sauber und richtig aufloesen koennen. Hinzu kamen weitere
Probleme und so entschied man sich, diesen Schritt zu machen. Der Witz ist, so
gross sind die Aenderungen nicht. Ein paar Aenderungen am Namemangeling, mal
hier ein Stackslot mehr, kleinigkeiten. Nur halt nicht kompatibel, im besten
Fall ein Linkerfehler oder Absturz, im schlechtesten Fall Datenkorruption. Denn
weil die Aenderungen so klein waren kann ein kleines Programm vielleicht doch
Problemlos gegen die neue libstdc++ laufen.
Im Normalfall sollte das nicht passieren. Es gibt Version fuer shared libs, die
Nummer hinter dem .so. .5 fuer die alte ABI, .6 fuer die neue.
Haken an der Sache:
Ein altes Programm zieht die libstdc++v.so.5, es loest seine Symbole gegen sie
auf. Es zieht weiterhin eine C++-lib, die gegen die neue libstdc++ gebaut wurde,
sie zieht die libstdc++.so.6.
Jetzt hat der Runtime-Linker zwei Bibliotheken, die beide das gleiche zur
verfuegung stellen. Damit kommt er klar, nur in einer fuer dieses Problem
unguenstigen Weise: Was er kann (er unterscheided das nur nach Namen) holt er
aus der alten libstdc++, was er vieleicht nicht findet aus der neuen. Wir haben
ein lustiges Mischmasch aus neuer und alter ABI. Das Programm selber ist
vielleicht so minimal, das es ihm noch nicht mal auffallen wuerde, was meist
knallt sind dann die Interna der einzelnen Libs die Falsch zusammen gelinkt
werden. (Allokator aus der neuen Lib benutzt Helper aus der alten Lib, aua)
Warum die Zeit hier nicht das Problem geloest hat?
Unsere geliebten Enterprise Distros deren aeltere Versionen wie Untote einfach
*stab* nicht *stab* sterben *stab* wollen. Den wie man sieht, man zieht am
besten das ganze System dann auf die neue ABI, aka neuer Compiler und das geht
natuerlich fuer Enterprise nicht.
Wie ich grad sehe ist der firefox 3 wohl jetzt auch gegen libstdc++.so.6 gebaut,
auf nem neueren RotHut. Das wird dann nicht auf System aelter 3-4 Jahren laufen.
Ist aber wohl verschmerzlich. Wer so ein altes System hat, der hat andere Sorgen
(oder auch keine)...

Und es soll wohl danach noch in einigen Supersonder-Randbereichen leichte
ABI-problemchen geben haben, die aber keinen Versionsbump nachsich gezogen haben.
Denn das war nur die Binaer-Sache. Diese Binaerspielchen haben aber eine
Ursache: Die Sprache ist einfach zu komplex, Fehler in der Implementierung oder
schon im Standard sind vorprogrammiert. Das fuehrt dann beim eigentlichen bauen
zu noch weiteren breakages. Sicher, die Sorgen hat der User seltener, macht aber
das langfristige warten und pflegen von sowas einen Alptraum, mal grade ein
Relaese machen weil es ein Sicherheitsproblem gibt ist dann vielleicht nicht.

Beispiel: GCC hatte einen Bug in seinem Templateparser gefixt. Das Ding hat
einfach Sachen angenommen, die so nicht vom Standard erlaubt und auch keine
angekuendigte Erweiterung waren. Repariert und nicht so gelassen hat man es, da
es teilweise broken Code erzeugt hat. Ui, Irgendwo fand sich danach in jedem
groesseren Projekt Templates in denen wohl einer mit Dead-Chicken-Programmierung
(so lange Klammern, Komma und Doppelpunkte drueber streuen bis es geht) das
irgendwie zum laufen gebracht hat...
Binary only CS loest das dann meist gern damit, das sie sich auf ein
"known-to-work"-Compiler Release zurueckfallen laesst auf dem dann solange
rumgeritten wird, bis das nicht mal mehr baut. Dann ist ploetzlich Polen offen
und der Arsch brennt...

Und was uns da an Major fuckups noch bevor steht ist eben, dank komplexitaet der
Sprache, nicht abzuschaetzen.

Also Kinder: C++ is evil!

> Also, das Startprogramm für Windows habe ich ja in C++, genauer gesagt
> in C mit ein bißchen C++-Syntax, also ohne Klassen ...
> 
> Update nach kurzem Test: Ich habe C geschrieben, ohne es zu wissen. Kein
> Wunder, denn C++ habe ich nur einmal vor Jahren in einem Buch angeschaut
> (und mich dann für Java entschieden). Ich hatte es nur aufgrund meiner
> sehr alten C-Kenntnisse für C++ gehalten: inzwischen darf ich variable
> Argumente mit "..."

An was? An Funktionen war das schon immer legal, was glaubst du wie sonst printf
funzt?
An Makros? Moment... vor C99 war das eine GCC-Erweiterung, nach C99 geht das
auch nach Standard, C99 hat dafuer aber eine andere Syntax als die GCC-Erweiterung.

> ausdrücken und Variablendeklarationen auch an
> anderen Stellen als am Anfang von Funktionen unterbringen,

Seit C99 allgemein zulaessig, davor als GCC-Erweitung
Genauso wie C++-Kommentare ("//").

Du kannst mit "-std=c99" oder "-std=gnu99" das verhalten vorgeben.

> damit verlasse ich noch nicht C, zumindest laut dem vom mingw installierten
> gcc. Also, mein Source ist C. :-)
> 

Bist du dir da ganz sicher? Das Programm Namens "gcc" ist der sogenannte
"compiler driver", das versucht anhand der Dateiendung rauszufinden, welche
Sprache es am besten versucht zu kompilieren (und ob es kompilieren oder linken
soll). Dateien mit der Endung gross-C werden als C++ uebersetzt, und das ist auf
Windowssystemen mit seinem IgnoreCase geschwurbel nicht besonders praktisch...

> Ich habe den Source in einen allgemeinen und einen systemspezifischen
> Teil aufgeteilt, d.h. einige Funktionen (und Konstanten) muß eine
> Source-Datei systemspezifisch implementieren. Unter anderem void
> alert(char*) und int confirm (char*). Ich habe nichts dagegen, in diesem
> Funktionen mit system() auch ein anderes Binary oder ein Shell-Skript
> einzubinden. Da habe ich auch den Mut, von der Existenz von z.B. "cp -r"
> auszugehen. :-)
> 

klein-"-r" ist laut neustem POSIX obsolete, gross-"-R" solls sein, aber ich
wuerds erstmal nicht aendern, wer weiss welches cp das sonst wieder nicht frist...

>> Ich versuchte dir klar zu machen, das du mit dem Kopf durch die Wand willst.
> 
> Schon klar :-) Ich rechne auch damit, daß ich das Problem nicht mehr
> lösen kann, bevor wir Ende dieser Woche eine Version in Auftrag geben.

Aua, nagut, eine Woche, da ist testen dann natuerlich knapp.

> Die wird in dem Fall ohne die schöne Update-Funktionalität auskommen müssen.
> 

Nooo! Lieber eine manchmal nicht funzende als garkeine? Denn den Browser nicht
upzudaten ist irgendwie fruchtlos (So aus Sicherheitssicht, was die Privacy
irgendwie ueber den Haufen werfen koennte...). Oder doch besser keine weil sich
der User in SIcherheit wiegt und sagen "holen sie sich doch bald mal nen Neuen
Stick bei uns"?

> Die Problematik des statischen Verlinkens - große Binaries,

Was ich vergessen habe zu erwaehnen:
Das nervige an grossen Binaries ist der warscheinlich hoehere Speicherverbrauch.
Und das kann auf Systemen mit weniger RAM dann unerfreulich sein.

> Verantwortung für Updates, Entscheidungen, was man statisch linkt und
> was nicht - sind mir schon bekannt. Da müßte man ein bißchen
> experimentieren. Ich weiß, daß es keine perfekte Lösung gibt - wir
> werden es darauf ankommen lassen müssen, welche Support-Anfragen wir
> bekommen,

Hmmm, nagut, solange du es noch so sehen kannst, ich dachte es ist die
Extremvorbereitung: Man gibt so einen Stick aus der Hand und man sieht und hoert
5 Jahre nix, in der das moeglichst Optimal laufen soll.

> und in einigen Fällen werden wir nicht helfen können.
> 
> Thomas:
>> Die LSB definiert doch genau einen Teil der Schnittstellen, die hier 
>> gesucht werden.
> 

Danke Thomas, ja, LSB lag mir auch auf der Zunge, dachte aber eher, das die da
noch Pfadvorgaben und Startscripte zusammen schustern, und sich zu einem
"libgtk.so muss vorhandensein" noch nicht geaeussert hatten. Aber das kann
Sebastian ja nachsehen, was er ja wohl auch getan hat.

[snip]
> 
> Hm, ich habe gerade von http://xdialog.free.fr/ die Sourcen geholt und
> auf einem Linux-Rechner der Uni Bielefeld, Mathe-Fakultät zu bauen
> versucht, aber configure sagt, es sei kein GTK vorhanden, eine Suche
> nach "gtk-config" bestätigt es ... GTK an sich kann mir aber nicht
> fehlen, wenn Ralf recht hat, daß Firefox GTK 2.x voraussetzt,
> wahrscheinlich fehlen mir nur die gtk*-devel-Pakete.

Richtig.

> Vorausgesetzt, ich finde in Linux, in dem ich das übersetzen kann: könnt ihr mich beraten,
> welche Linker-Optionen ich einsetzen sollte für ein Binary, das auf
> möglichst vielen mich interessierenden Linuxen läuft?

Hmmm, recht minimalistisches Programm, zum glueck in C.

Bau es mit GTK2 unterstuezung, GTK1 ist auf neueren Distros nicht mehr
vorhanden. Umgekehrt sollten 4 Jahre zurueck die Distros GTK neu genug haben.
Das sollte ganz gut zu Firefox 3 und der libstdc++.so.6 passen.

$ objdump -T Xdialog | grep GLIBC
00000000      DF *UND*  00000163  GLIBC_2.0   fputs
00000000      DF *UND*  0000001d  GLIBC_2.0   __errno_location
00000000      DF *UND*  00000034  GLIBC_2.0   sprintf
00000000      DF *UND*  0000008b  GLIBC_2.1   popen
00000000      DF *UND*  00000036  GLIBC_2.0   localtime
00000000      DF *UND*  00000167  GLIBC_2.0   strchr
00000000      DF *UND*  000000ef  GLIBC_2.0   getenv
00000000      DF *UND*  000000a3  GLIBC_2.0   strncpy
00000000      DF *UND*  0000017c  GLIBC_2.0   fgets
00000000      DF *UND*  00000043  GLIBC_2.0   memset
00000000      DF *UND*  00000045  GLIBC_2.0   __strtol_internal
00000000      DF *UND*  000001b9  GLIBC_2.0   __libc_start_main
00000000      DF *UND*  00000015  GLIBC_2.0   bindtextdomain
00000000      DF *UND*  00000048  GLIBC_2.0   getopt_long_only
00000000      DF *UND*  0000007a  GLIBC_2.0   read
00000000      DF *UND*  0000003f  GLIBC_2.0   scanf
00000000      DF *UND*  00000043  GLIBC_2.0   dcgettext
00000000      DF *UND*  00000113  GLIBC_2.0   fseek
00000000      DF *UND*  00000219  GLIBC_2.1   fclose
00000000      DF *UND*  000000af  GLIBC_2.0   strlen
00000000      DF *UND*  00000033  GLIBC_2.1   fopen
00000000      DF *UND*  0000065c  GLIBC_2.0   setlocale
00000000      DF *UND*  00000101  GLIBC_2.0   fgetc
00000000      DF *UND*  00000020  GLIBC_2.0   strcpy
00000000      DF *UND*  00000201  GLIBC_2.0   ftell
00000000      DF *UND*  00000052  GLIBC_2.0   strcasecmp
00000000      DF *UND*  0000017d  GLIBC_2.0   fwrite
00000000      DF *UND*  00000024  GLIBC_2.0   fprintf
00000000      DF *UND*  00000186  GLIBC_2.0   strstr
00000000      DF *UND*  00000020  GLIBC_2.0   time
00000000      DF *UND*  000000b8  GLIBC_2.0   strncat
00000000      DF *UND*  00000111  GLIBC_2.0   fputc
00000000      DF *UND*  00000058  GLIBC_2.0   memmove
00000000      DF *UND*  000001aa  GLIBC_2.0   strcat
00000000      DF *UND*  0000011b  GLIBC_2.0   textdomain
00000000      DF *UND*  000000c6  GLIBC_2.0   fcntl
00000000      DF *UND*  0000019b  GLIBC_2.0   memchr
00000000      DF *UND*  000000f3  GLIBC_2.0   strncmp
00000000      DF *UND*  00000141  GLIBC_2.0   fread
00000000      DF *UND*  00000025  GLIBC_2.0   strcmp
00000000      DF *UND*  000000f1  GLIBC_2.0   exit
00000000      DF *UND*  00000021  GLIBC_2.1   pclose
0805ee00 g    DO .bss   00000004  GLIBC_2.0   stdout
0805edf4 g    DO .bss   00000004  GLIBC_2.0   stderr
0805edf8 g    DO .bss   00000004  GLIBC_2.0   stdin
0805ee14 g    DO .bss   00000004  GLIBC_2.0   opterr
0805edf0 g    DO .bss   00000004  GLIBC_2.0   optind
0805ee18 g    DO .bss   00000004  GLIBC_2.0   optarg

Die versionierten Symbole der libc sehen gut aus, ich denke nicht das man dafuer
einen Handstand machen muss. Bleibt noch die GTK abhaengigkeit, aber das muss eh
da sein fuer Firefox.

Du willst LDFLAGS="-Wl,--as-needed", aber das ist bei gtk-Programmen immer mit
vorsicht zu geniessen, mach ein paar tests, obs wie gewuescht laeuft.

Du willst das ganze vielleicht auf einem RHEL 4.6 (sprich das richtige centos),
Fedora 4, vielleicht Debian 3.1 Sarge, SuSE je nachdem wie du aeltere Versionen
findest ab 9.3 bauen (oder vergleichbares, die hab ich jetzt mal diese tolle
erfindung durchgeguckt:
http://distrowatch.com/table.php?distribution=redhat
http://distrowatch.com/table.php?distribution=fedora
http://distrowatch.com/table.php?distribution=debian
http://distrowatch.com/table.php?distribution=SuSe
Schau dabei auf GCC-Version, glibc-version, gtk+-Version)

Pack dir die Distro in ne VM, chroot (achtung, advanced), oder grad einen
Rechner der alt genug ist. Du musst keine Geschwindigkeitsrekorde aufstellen,
nur grad ein kleines Programm bauen (geht auch ohne X ;), nur dann zum testen)
achja, benoetigte devel-packete insten.

Ich denke nicht das da irgendwas gross statisch gelinkt werden muss.
Ausser...
Hmmm, ich bin grad noch am ueberlegen wegen der Version der glib (nicht glibc!)
ob die 1.2 oder 2.0 und welche und sowieso und ueberhaupt. Besonders wenn du
eine statisch reinlinkst koennte gtk allergisch reagieren.
Versuchs erstmal ohne statisches linken und kopier das Binary dann ein bischen
rum ums auszuprobieren

> Also eben solche, auf denen auch Firefox läuft - Xdialog kann auch mit GTK2 verwendet
> werden, und die auf "http://xdialog.free.fr/doc/changelog.html" dafür
> genannten Probleme treffen auf mich wahrscheinlich nicht zu, weil ich
> mich in meinen Texten auf US-ASCII beschränke.
> 

Eben, und immer daran denken, wenn Firefox nicht laeuft, braucht deine Loesung
auch nicht richtig laufen ausser zu sagen: "Bitte Soft nach insten oder System
updaten".
Mehr ist in einer Woche wohl nicht zu Retten (z.B. ganzen Library Zoo mitbringen).

> Sebastian
Gruss
	Jan

-- 
C(_) C(_) C(_) C(_) C(_) C(_) C(_) C(_) C(_) C(_) C(_) C(_) C(_) C(_)