Moin Moin, Am Samstag, 1. Juni 2002 03:12 schrieb David Haller:

Wieso kommt ihr mir hier alle so bekannt vor? *g* Jetzt muessen wir nur noch die Profis herlocken ;)

Bestimmt werden sich hier einige Verlaufen :)

==== make [..][2] install [Teil 1] ==== mkdir /var/tmp/rpm/gtk2-2.0.2-buildroot/opt/gnome2/lib/gtk-2.0/2.0.0/lo aders /bin/sh ../libtool --mode=install /usr/bin/ginstall -c libpixbufloader-png.la /var/tmp/rpm/gtk2-2.0.2-buildroot/opt/gnome2/lib/gtk-2.0/2.0.0/lo ad libtool: install: warning: relinking `libpixbufloader-png.la' (cd /usr/src/packages/BUILD/gtk+-2.0.2/gdk-pixbuf; /bin/sh ../libtool --mode=relink gcc -O2 -march=athlon -mcpu=athlon -malign-functions=4 -fsched mv: libpixbufloader-png.so: No such file or directory

Bist Du schon mal durch die Unterverzeichnisse der sourcen gesurft? Ich hatte ähnliche Probleme mit Qt-3.0.4. Ich musste in diversen Verzeichnissen die library's zusätzlich mit make kompilieren, erst danach lief ./install ordentlich durch. Ciao Andre

Hallo, ach, du auch hier? :) On Sat, 01 Jun 2002, Andre Heine wrote:

Am Samstag, 1. Juni 2002 03:12 schrieb David Haller:

...

Wieso kommt ihr mir hier alle so bekannt vor? *g* Jetzt muessen wir nur noch die Profis herlocken ;)

Bestimmt werden sich hier einige Verlaufen :)

Hoffentlich :) [Probleme beim compile/install von gtk2]

Bist Du schon mal durch die Unterverzeichnisse der sourcen gesurft?

Jein[1].

Ich hatte ähnliche Probleme mit Qt-3.0.4. Ich musste in diversen Verzeichnissen die library's zusätzlich mit make kompilieren, erst danach lief ./install ordentlich durch.

Ist in dem Fall nicht noetig, in der Beziehung klappt alles, wir fein saeuberlich rekursiv durch die Verz. abgestiegen und kompiliert... Gerade laeuft das 'rpm -bi' mit dem aktuellen autoconf/-make und libtool, bisher scheint's zu tun... Gleich evtl. mehr im anderen Subthread. -dnh [1] das gehoert auch schon zu meiner "Trickkiste" ;) -- Java ist böse, man darf es nicht verwenden, wenn man es tut muß man dafür be- zahlen. Natürlich ist auch C böse. Nur ist die Boshaftigkeit von C die eines guten Jedi, gerecht, nicht verzeihend, die reinigende Flamme wohingegen die Macht von Java der dunklen Seite gleicht, verlockend, einfach und fast unentrinnbar wenn man davon azte... -- Dietz Proepper

Hallo, On Sat, 01 Jun 2002, David Haller wrote:

...

Ich schaue mir mal gtk2 an, denn so sehe auch ich nicht, wo das Problem liegt.

Musst du wohl nicht, ich bin mir fast sicher, dass es an libtool und Konsorten liegt... Ich meld' mich nochmal, wenn ich's mit den aktuellen Tools probiert habe.

Hat auch nicht geklappt. Offensichtlich war gtk+-2.0.2 b0rken. Mit -2.0.3 scheint's jetzt geklappt zu haben (hab's nur nochmal durchlaufen lassen, hab aber noch nicht das log kontrolliert, da ich zu muede bin, allerdings wurden libgdk und libgtk nun installiert (im Ggs. zu vorher)). Evtl. teste ich morgen oder so sogar nochmal mit dem alten autoconf/-make und libtool... Im ChangeLog find ich aber grad nix dazu... Naja, dann kann's ja morgen dann weitergehen ;) -dnh PS: Ich bastel parallel ein Makefile dazu, in dem ich die deps des Build-Prozesses "festhalte"[0] ;) Im Idealfall reichen dann die Sourcen, die .specs, das Makefile und ein 'make -f Makefile.gnome2' :) Im Moment bin ich bei: /usr/src/packages/SPECS $ ARCH=athlon make -f Makefile.gnome2 Checking for autoconf-2.53... autoconf-2.53-1_dh_1 Checking for automake-1.6.1... automake-1.6.1-1_dh_1 Checking for libtool-1.4.2... libtool-1.4.2-1_dh_1 Checking for gtk-doc-0.9... gtk-doc-0.9-1_dh_1 Checking for glib2-2.0.1... glib2-2.0.1-1_dh_1 Checking for atk-1.0.1... atk-1.0.1-1_dh_1 Checking for pango-1.0.1... pango-1.0.1-1_dh_1 Checking for gtk2-2.0.3... package gtk2-2.0.3 is not installed Building gtk2-2.0.3-1_dh_1.athlon.rpm... rpm -ba gtk2.spec > gtk2.spec.log 2>&1 Installing gtk2-2.0.3-1_dh_1.athlon.rpm... Password: su: incorrect password make: *** [gtk2-2.0.3-1_dh_1.athlon.rpm] Error 1 (das PW war <enter> und mit Absicht falsch, s.u.) Tja, und da, bei gtk2 (mit -2.0.2) war ich haengengeblieben und mach heute auch nicht mehr weiter ;) Der eigentliche Build ist im Moment eben durch ein echo davor entschaerft, da ich ja (noch) alles von Hand machen muss, das ARCH= ist noetig, weil: 'ARCH ?= $(shell uname -m)' und das liefert bei mir eben nur ein i686, ich hab aber nen gepatchten pgcc-2.95.3 (basiert auf gcc 2.95.2, nicht .3!), und dafuer hab ich mir in rpm eben 'athlon' als 'arch' definiert :) Fuer andere sollte aber obiger default `uname -m` passen, aber wie man sieht, kann man das auch leicht "ueberschreiben" :) Hm. Build und Install sollte ich wohl noch durch ein && verknuepfen oder so... Jedefalls ist (leider) bisher fast bei jedem Paket ein install noetig, bevor das naechste kompiliert werden kann... Ob/Wie ich das jetzige 'su -c "$(RPM) ..."' noch ersetze (z.B. mit Aufforderung/Abfrage + Ueberpruefung, dass man als root (z.B. auf ner anderen Konsole/xterm) das rpm installieren soll) darueber gruebel ich noch ;) Da ich mich ja aber grad "per Hand" vortaste (und die Pakete dann jew. per Hand (testend) als root installiere) hat das noch Zeit... Ausserdem will ich ggfs. auch explizite Abhaengigkeiten zu einer evtl. noetigen Installation herstellen, so dass man nicht unnoetig oft "eingreifen" muss :) Achso, Philipp, die Specs sind relativ SuSE-konform[1], aber wohl kompatibel, koennte euch evtl. dann Arbeit ersparen (weniger an den Defs usw. im .spec, mehr dabei wie der Kram kompiliert werden muss ;) Melde dich bei Interesse, ich pack die specs jederzeit gern in nen tarball :) PPS: Welche(s) kranke(n) Hirn(e) ha(t|ben) offenbar ein make prefix=... bindir=... libdir=... ... install zum "Standard"[2] gemacht??? (das findet sich naemlich in allen Gnome2-specs aus den tarballs, die ich bisher angefasst habe (s.o.)). Ein simples 'make DESTDIR=... install' stattdessen hat's bisher noch immer getan, denn es wird (in denen) eben autoconf/-make verwendet ohne an den install-Targets rumzupfuschen (also eben mit einem $(DESTDIR) vor'm jew. Ziel des install :) PPPS: 8:0??? Wuff!!! :)) [0] Primaer, um's dann beim release einfacher zu haben... Im Moment backe ich ja an der beta5 rum ;) Wenn's klappt muss ich fuer's release dann nur ein paar Versions-infos aktualisieren (ok, das ist im Moment noch nicht sonderlich intelligent geloest, jew. einmal im include-file fuer das Makefile, und einmal als define im jew. spec), aber dann sollte ein 'make -f Makefile.gnome2' sowie (im Moment) x-mal das root-PW (fuer die 'rpm -i...' eingeben) reichen, um dann gnome2 zu backen und (sauber und komplett in /opt/gnome2) zu installieren, ohne das laufende System auch nur irgendwie zu beeintraechtigen :) Bisher klappts, es ist _alles_ (inkl. seit vorhin autoconf/-make und libtool) komplett und ausschliesslich in /opt/gnome2. Sicher, ich werde PATH, ld.so.conf, INFOPATH, MANPATH usw. erweitern muessen, aber das ist mir das allemal wert. Zur Deinstallation wuerde ohne rpm ein 'rm -rf /opt/gnome2' reichen (sowie in /etc/ ein paar Variablen wieder verkuerzen), mit rpm geht z.B.: "rpm -qal | grep '^/opt/gnome2' | xargs rpm -qf | sort -u | xargs rpm -e" (geht sicher auch noch eleganter ;) Apropos: bis inkl. zum sort spuckt das (s.o.) im Moment aus (mit ',' statt Zeilenumbruch: atk-1.0.1-1_dh_1, atk-devel-1.0.1-1_dh_1, autoconf-2.53-1_dh_1, automake-1.6.1-1_dh_1, glib2-2.0.1-1_dh_1, glib2-devel-2.0.1-1_dh_1, gtk-doc-0.9-1_dh_1, libtool-1.4.2-1_dh_1, pango-1.0.1-1_dh_1, pango-devel-1.0.1-1_dh_1, pkgconfig-0.12.0-1_dh_1 Auch nett (ich begeistere mich grad einfach mal wieder fuer Unixoides und ein auch nur halbwegs gescheites Paketmanagement a la RPM): # rpm -qal | grep '/opt/gnome2' | xargs rpm -qf | sort -u | \ xargs rpm -q --queryformat "%{installtime}\n" | sort -n | \ xargs epochtodate Thu 30.05.2002 21:58:40 CEST Thu 30.05.2002 22:51:50 CEST Thu 30.05.2002 23:55:46 CEST Thu 30.05.2002 23:55:55 CEST Fri 31.05.2002 02:31:01 CEST Fri 31.05.2002 02:31:02 CEST Fri 31.05.2002 05:25:05 CEST Fri 31.05.2002 05:25:15 CEST Sat 01.06.2002 23:30:24 CEST Sat 01.06.2002 23:31:00 CEST Sat 01.06.2002 23:33:23 CEST (wobei ein "%{installtime:date}\n" fuer die meisten Faelle wohl reicht, aber das finde ich weniger lesbar ;) Oh, ein 'rpm -qa | wc -l' liefer bei mir "schlappe" '1029'. Auch nett: $ rpm -qa --queryformat "%{size}\n" | sed 's/$/+/g;' | \ xargs echo | sed 's/+$//;' | bc | xargs echo | sed 's/ /+/g;' | bc 3130458323 Und noch ein Apropos: ich hab heut mal wieder Win95 gebootet, um ein wenig MM6 zu spielen, und hab vorher noch ein wenig rumgewurschelt, und jep, prompt hab ich die Moeglichkeiten der bash, sed, awk, grep, rpm usw. pp. vermisst :) Mannmannmann, was hab ich ehedem verpasst, als ich Linux (bzw. ein anders Unixoides System) noch nicht kannte, das kommt meiner Arbeitsweise sooo entgegen :) Ich fuehl mich immer so amputiert, wenn ich unter Win was machen will (ausser ein Spiel zu starten ;)... [1] Aber eben in meinem Stil, mit nem Haufen %define's zu Beginn, die meisten davon, weil ich zu faul bin, die _libdir usw. zu ersetzen. Alles ab %prep sollte aber weitestgehend passen. [2] Aus nem %changelog: - Updated spec file to match gpp standard -- Ich sag's ja, ...diese abolut warmduschende Meute von "Vollquotern" steigt. [Clemens Wohld in suse-linux]

David Haller [2 Jun 2002 03:03:46 +0200]:

...

Welche Version von libtool hast du denn benutzt?

1.3.3

Aktuell ist 1.4.2 und da haben sich einige Veränderungen ergeben. Philipp

Hallo Philipp, On Sun, 02 Jun 2002, Philipp Thomas wrote:

David Haller [2 Jun 2002 03:03:46 +0200]:

...

...

Welche Version von libtool hast du denn benutzt? 1.3.3

Aktuell ist 1.4.2 und da haben sich einige Veränderungen ergeben.

Ich weiss (da hast du meine mail zu oberflaechlich gelesen ;). Ich hatte bei der letzten Mail schon libtool-1.4.2-1_dh_1 im Einsatz, das mit 1.3.3. bezog sich auf die (nachtraegliche) Analyse... Wie in der letzten Mail geschrieben gab's auch mit dem aktuellen 1.4.2 noch den gleichen Fehler. (die anderen Fehler gab's dann, wenn ich das libtool im tarball z.B. mit dem 'libtoolize --force' explizit durch die alte Version 1.3.3 ersetzt habe). Der Fehler lag also _nicht_ an automake/-conf/libtool sondern an gtk2 selbst. Ich hatte heute aber keine Lust, dem weiter nachzugehen (und die aktuellen Versionen eben nochmal zu deinstallieren/deaktivieren) um zu testen ob's dann gegangen waere. Jedenfalls: der Build mit gtk+-2.0.3 hat nun (fast) einwandfrei geklappt, im log (rpm -ba 2>&1 | tee ...) tauchen nur noch ein paar Warnings bzgl. '-Wunsigned' und IIRC einmal ein "missing case in switch"[1] auf. Achso: Falls es dich explizit interessiert, teste ich auch nochmal mit den alten Versionen von autoconf/-make/libtool... -dnh PS: *ARGL* Ist's nun 'libIDL2' oder 'libIDL'? Das ist ja sowas von konfus, die Autoren koennen sich offensichtlich nicht entscheiden! *grummel* Trotzdem inzwischen bei ORBit angekommen seiend ;) [1] das lass ich auch so, das switch-Statement enthielt nur einen Fall, AFAIK faellt alles andere also sowieso durch, ein expliziter 'default:'-case ist in dem Fall AFAIK ueberfluessig: switch(foo) { case BAR: do_something(); break; } dass 'foo' hier noch mehr Werte als BAR annehmen kann ist doch egal, oder? Im Endeffekt ist's ja nur ein: if(foo == BAR) { do_something(); } (hier interessieren die moeglichen anderen Werte von foo ja auch nicht ;) -- Today on Handyman's Corner, we're going to take some ordinary dice, some Bondo to fill in the holes, a Dremel tool with a pointy bit to carve the words "REBOOT", "RETRY", and "REINSTALL" in the faces, and a bit of paint to make it look pretty. ITWDFYHTSALFYH. [A. de Boer on adminning Win]

Hi,

dass 'foo' hier noch mehr Werte als BAR annehmen kann ist doch egal, oder? Im Endeffekt ist's ja nur ein:

if(foo == BAR) { do_something(); }

(hier interessieren die moeglichen anderen Werte von foo ja auch nicht ;)

Ja, meine ich auch. "switch" ist fast wie "if". Nur das BAR ein Integer sein muß. string oder char funktioniert IMHO nicht mit swich ( warum nur??) Ciao Andre

Am Mon, 2002-06-03 um 08.12 schrieb David Haller:

Hallo Philipp,

On Sun, 02 Jun 2002, Philipp Thomas wrote:

...

David Haller [2 Jun 2002 03:03:46 +0200]:

...

...

Welche Version von libtool hast du denn benutzt? 1.3.3

Aktuell ist 1.4.2 und da haben sich einige Veränderungen ergeben.

(die anderen Fehler gab's dann, wenn ich das libtool im tarball z.B. mit dem 'libtoolize --force' explizit durch die alte Version 1.3.3 ersetzt habe). Die Fehlermeldung deutet auf Verwendung von "Convenience-Libs" hin. Diese werden von libtool erst ab 1.4 unterstützt.

Achso: Falls es dich explizit interessiert, teste ich auch nochmal mit den alten Versionen von autoconf/-make/libtool... Um ein Paket vom tarball zu übersetzen, brauchst Du keines dieser Tools.

PS: *ARGL* Ist's nun 'libIDL2' oder 'libIDL'? Das ist ja sowas von konfus, die Autoren koennen sich offensichtlich nicht entscheiden! *grummel* Stichwort: Versioning.

Es ist eine recht einfache Methode um Parallelinstallationen inkompatibler Libraries, Binaries u.ä. zu ermöglichen. [Gtk2 und Gnome2 sind source-code- und binär-inkompatibel.] Ralf

On Tue, 04 Jun 2002 at 10:31 (+0200), Andre Heine wrote:

From: Philipp Thomas

...

"Andre Heine" [4 Jun 2002 08:37:22 +0200]:

...

string oder char funktioniert IMHO nicht mit swich ( warum nur??)

char funktioniert sehr wohl, wird allerdings zu int aufgeweitet. Sonst könntest du ja auch nicht Kommandozeilen-Optionen mit switch abhandeln:

Ok, man kann aber nur ein einzelnes Zeichen benutzen. Ich persönlich würde es begrüssen, wenn string auch funktionieren würde :))

Kling recht logisch, quasi jedes konsolen-tool kennt diese Schalter, hätte ich eigentlich selber drauf kommen können.

Naja, normalerweise sollte jedes Konsolentools getopt() benutzen. Damit wird sichergestellt, dass sich jedes Programm bei Schaltern gleich verhält.

...

String funktioniert tatsächlich nicht, denn ein String lässt sich nun mal nicht auf einen ganzzahligen Ausdruck reduzieren.

Schade eigentlich, wäre ein Feature. Man würde etliche Zeilen Konvertierungen sparen. IMHO finde es besser, mit langen strings zu arbeiten. Der Quellcode ist meist viel besser zu lesen.

Ich weiß jetzt nicht, wie Du das meinst aber oft eignen sich auch Konstanten (also #define ...). Dadurch wird der Quellcode lesbar, man arbeitet im Prinzip aber nur bspw. mit int-Werten. Gruß, Bernhard -- "Was ökonomisch auf Dauer falsch ist, kann politisch auf Dauer nicht richtig sein." -- Franz Vranitzky

Hallo, On Tue, 04 Jun 2002 at 12:56 (+0200), Andre Heine wrote:

From: Bernhard Walle

...

On Tue, 04 Jun 2002 at 10:31 (+0200), Andre Heine wrote:

...

From: Philipp Thomas

...

"Andre Heine" [4 Jun 2002 08:37:22 char funktioniert sehr wohl, wird allerdings zu int aufgeweitet. Sonst könntest du ja auch nicht Kommandozeilen-Optionen mit switch abhandeln:

Ok, man kann aber nur ein einzelnes Zeichen benutzen. Ich persönlich würde es begrüssen, wenn string auch funktionieren würde :))

Kling recht logisch, quasi jedes konsolen-tool kennt diese Schalter, hätte ich eigentlich selber drauf kommen können.

Naja, normalerweise sollte jedes Konsolentools getopt() benutzen. Damit wird sichergestellt, dass sich jedes Programm bei Schaltern gleich verhält.

getopt() kenne ich leider nicht, habe damit noch nicht gearbeitet. Kommt aber bestimmt auch noch...

Ist eigentlich ganz simpel, sieh "man 3 getopt". Das 'normale' getopt, also für kurze Flags, ist in "unistd.h" drin, sollte also auf jedem unixoiden OS funktionieren. Übrigens gibt es bei Perl auch Getopt::Std und Getopt::Long. Beide sind im Standard-Perl-Lieferumfang enthalten. Man sollte sie eigentlich immer verwenden. Nimmt einem Arbeit ab und man kann keine Fehler machen. ;-) Gruß, Bernhard -- I've no idea when Linus is going to release 2.0.24, but if he takes too long I'm going to release a 2.0.24unoff and he can sound off all he likes. -- Alan Cox

Am Die, 2002-06-04 um 13.11 schrieb Bernhard Walle:

Hallo,

On Tue, 04 Jun 2002 at 12:56 (+0200), Andre Heine wrote:

...

From: Bernhard Walle

...

On Tue, 04 Jun 2002 at 10:31 (+0200), Andre Heine wrote:

...

From: Philipp Thomas

...

"Andre Heine" [4 Jun 2002 08:37:22 char funktioniert sehr wohl, wird allerdings zu int aufgeweitet. Sonst könntest du ja auch nicht Kommandozeilen-Optionen mit switch abhandeln:

Ok, man kann aber nur ein einzelnes Zeichen benutzen. Ich persönlich würde es begrüssen, wenn string auch funktionieren würde :))

Kling recht logisch, quasi jedes konsolen-tool kennt diese Schalter, hätte ich eigentlich selber drauf kommen können.

Naja, normalerweise sollte jedes Konsolentools getopt() benutzen. Damit wird sichergestellt, dass sich jedes Programm bei Schaltern gleich verhält.

getopt() kenne ich leider nicht, habe damit noch nicht gearbeitet. Kommt aber bestimmt auch noch...

Ist eigentlich ganz simpel, sieh "man 3 getopt". Das 'normale' getopt, also für kurze Flags, ist in "unistd.h" drin, sollte also auf jedem unixoiden OS funktionieren. Schön wär's - Ist aber nicht - getopt gehört zu den Klassikern unter den Portabilitätsproblemen.

"getopt(3) in " wird zwar von den neuesten Standards [1] gefordert, doch ist dem in Realität bei weitem nicht der Fall. So ist getopt(3) auf manchen Systemen auch in zu finden (Z.B. Solaris), auf anderen Systemen ist es zwar vorhanden, aber in keinem Header zu finden, ... Weiterhin variieren die Details zwischen unterschiedlichen OSen ganz erheblich. So ist z.B. nicht sichergestellt, dass optarg, optind, opterr und optopt in oder deklariert sind oder ob lokale Deklarationen erforderlich sind. Unter Linux/glibc2 sind sie in , unter manch anderem OS nicht. Desweiteren gibt es auch getopt-Varianten, die nicht fehlerfrei funktionieren (Einige glibc2/Linux-Versionen gehören dazu). Ansonsten hat die getopt-Geschichte mit dem "C-switch" aber auch überhaupt nichts zu tun ... Ralf [1] Siehe http://www.opengroup.org/onlinepubs/007904975/