Hallo, ich versuche gerade ghostscript 6.51 zu bauen (aus gs_lib-6.51- 0.src.rpm von SuSE). Das ganze passiert unter 'ner 7.0. Alle Pakete bzw. libs, die in der neededforbuild section im spec-File stehen, sind installiert. Nun meckert er beim rpm bauen die libintl.a an, wenn er im Paket gimp-print-4.1.10 in src/escputil ist. Ich habe hier keine 7.0 CD's oder DVD's, daher kann ich die Paketauskunft nicht bemühen. Kann mir jemand sagen, in welchem Paket die steckt? Andreas BTW: Gibt es eigentlich für solche Fälle auch online die Möglichkeit festzustellen, welches Paket da fehlt bzw. wo die Library drin ist?
Hi Andreas, rpmfind.net macht dich glücklich ;) Am Montag, 8. Oktober 2001 08:04 schrieb Andreas Kyek:
Hallo,
ich versuche gerade ghostscript 6.51 zu bauen (aus gs_lib-6.51- 0.src.rpm von SuSE).
Das ganze passiert unter 'ner 7.0. Alle Pakete bzw. libs, die in der neededforbuild section im spec-File stehen, sind installiert. Nun meckert er beim rpm bauen die libintl.a an, wenn er im Paket gimp-print-4.1.10 in src/escputil ist.
Ich habe hier keine 7.0 CD's oder DVD's, daher kann ich die Paketauskunft nicht bemühen. Kann mir jemand sagen, in welchem Paket die steckt?
Andreas
BTW: Gibt es eigentlich für solche Fälle auch online die Möglichkeit festzustellen, welches Paket da fehlt bzw. wo die Library drin ist?
-- ___________________________ LINUX is like a wigwam, NO Gates NO Windows, but an Apache inside...
Moin, On Mon, 08 Okt 2001, Andreas Kyek wrote:
ich versuche gerade ghostscript 6.51 zu bauen (aus gs_lib-6.51- 0.src.rpm von SuSE).
Das ganze passiert unter 'ner 7.0. Alle Pakete bzw. libs, die in der neededforbuild section im spec-File stehen, sind installiert. Nun meckert er beim rpm bauen die libintl.a an, wenn er im Paket gimp-print-4.1.10 in src/escputil ist.
dh@slarty[6]:/newsw/SuSE (0) $ locate libintl.a dh@slarty[6]:/newsw/SuSE (0) $ rpm -qf /usr/include/libintl.h libc-2.1.3-65 dh@slarty[6]:/newsw/SuSE (0) $ Wie's scheint, gibt's die (hier ne ex-SuSE-6.2 nicht). Bug im .spec/configure/Makefile wie mir (s.u.) scheint, denn die funktionen in libintl.h sind in der glibc eingebaut...
BTW: Gibt es eigentlich für solche Fälle auch online die Möglichkeit festzustellen, welches Paket da fehlt bzw. wo die Library drin ist?
$MIRROR/ftp.suse.com/pub/suse/$VERSION/suse/contents/* dh@slarty[6]:/newsw/SuSE (2) $ grep -H libintl\. ftp.suse.com/pub/suse/7.2/suse/contents/* 2>/dev/null ftp.suse.com/pub/suse/7.2/suse/contents/clisp: /usr/lib/clisp/base/libintl.a ftp.suse.com/pub/suse/7.2/suse/contents/clisp: /usr/lib/clisp/full/libintl.a ftp.suse.com/pub/suse/7.2/suse/contents/clisp: /usr/lib/clisp/fullnox/libintl.a ftp.suse.com/pub/suse/7.2/suse/contents/cross-arm-glibc: /opt/cross/arm-linux/include/libintl.h ftp.suse.com/pub/suse/7.2/suse/contents/cross-ppc-glibc: /opt/cross/powerpc-linux/include/libintl.h ftp.suse.com/pub/suse/7.2/suse/contents/cross-s390x-glibc: /opt/cross/s390x-suse-linux-gnu/include/libintl.h ftp.suse.com/pub/suse/7.2/suse/contents/cross-x86-glibc: /opt/cross/i386-linux/include/libintl.h ftp.suse.com/pub/suse/7.2/suse/contents/glibc-devel: /usr/include/libintl.h (jew. per Hand nach dem : umbebrochen und ein tab[1] eingefuegt) -dnh [1] was mein xemacs aber (von mir gewollt) ersetzt. -- "wieso machts du ein zigarettenposting daraus. ach ja! Falls du nicht weisst was ein Zigarettenposting ist: Alles verdreht und irgendwo zusammen reingequetscht." [WoKo in dag°]
On 8 Oct 2001, at 8:52, David Haller wrote:
Moin,
On Mon, 08 Okt 2001, Andreas Kyek wrote:
ich versuche gerade ghostscript 6.51 zu bauen (aus gs_lib-6.51- 0.src.rpm von SuSE).
Das ganze passiert unter 'ner 7.0. Alle Pakete bzw. libs, die in der neededforbuild section im spec-File stehen, sind installiert. Nun meckert er beim rpm bauen die libintl.a an, wenn er im Paket gimp-print-4.1.10 in src/escputil ist.
dh@slarty[6]:/newsw/SuSE (0) $ locate libintl.a dh@slarty[6]:/newsw/SuSE (0) $ rpm -qf /usr/include/libintl.h libc-2.1.3-65 dh@slarty[6]:/newsw/SuSE (0) $
Wie's scheint, gibt's die (hier ne ex-SuSE-6.2 nicht).
Tja, genau das ist auch mein Problem!
Bug im .spec/configure/Makefile wie mir (s.u.) scheint, denn die funktionen in libintl.h sind in der glibc eingebaut...
BTW: Gibt es eigentlich für solche Fälle auch online die Möglichkeit festzustellen, welches Paket da fehlt bzw. wo die Library drin ist?
$MIRROR/ftp.suse.com/pub/suse/$VERSION/suse/contents/*
dh@slarty[6]:/newsw/SuSE (2) $ grep -H libintl\. ftp.suse.com/pub/suse/7.2/suse/contents/* 2>/dev/null
Das wäre 'ne Idee, die Infos demnächst selber zu ermitteln. (Hilft mir hier aber nicht, da das über unsere FW nicht geht. Und alle diese Dateien einzeln von Hand zu transferieren: Nein danke) Da werde ich mir wohl doch von zu Hause mal die CD's mitbringen müssen. BTW: Die library in den Paketen lisp* hilft mir natürlich nicht weiter. Der Fehler tritt beim rpm -b[ab] auf, wenn er gimp-print- 4.1.10 bauen will, dort dann beim Teil escputil. Da ich keinen Epson Drucker habe brauche ich das nicht. Aber wie um Himmels willen übersetzt SuSE das dann? Das SRPM ist AFAIK für die 7.2, daher muß ich neu übersetzen. Die rpm-Version wird auf meiner 7.0 nicht laufen (andere glibc!). Dein grep war auch für die 7.2. Spinne ich oder geht da was an mir vorbei? Gibt's die lib überhaupt auf der 7.2? Andreas (der gerade etwas ratlos ist)
On Mon, 08 Okt 2001, Andreas Kyek wrote:
On 8 Oct 2001, at 8:52, David Haller wrote:
dh@slarty[6]:/newsw/SuSE (0) $ locate libintl.a Wie's scheint, gibt's die (hier ne ex-SuSE-6.2 nicht). Tja, genau das ist auch mein Problem! [..] grep -H libintl\. ftp.suse.com/pub/suse/7.2/suse/contents/* 2>/dev/null Das wäre 'ne Idee, die Infos demnächst selber zu ermitteln. (Hilft mir hier aber nicht, da das über unsere FW nicht geht. Und alle diese Dateien einzeln von Hand zu transferieren: Nein danke)
Hmja... 36 MB laut 'du -hs' ;) Aber es sind halt v.a. viele (2586) Dateien, die Groesse ist weniger kritisch ;)
BTW: Die library in den Paketen lisp* hilft mir natürlich nicht weiter.
Klar. Ich wollte nur vollstaendig sein, dass es das auf 7.2 auch nicht gibt :)
Der Fehler tritt beim rpm -b[ab] auf, wenn er gimp-print- 4.1.10 bauen will, dort dann beim Teil escputil. Da ich keinen Epson Drucker habe brauche ich das nicht.
Aber wie um Himmels willen übersetzt SuSE das dann? Das SRPM ist AFAIK für die 7.2, daher muß ich neu übersetzen. Die rpm-Version wird auf meiner 7.0 nicht laufen (andere glibc!).
IMO is das ein Bug (wie erwahent). libintl ist in der glibc enthalten. Gerade die *gettext Funktionen der "libintl" sind: dh@slarty[3]:~ (1) $ nm /lib/libc.so.6 | grep gettext 0001b290 T __dcgettext 0001bc70 T __dgettext 0001bca0 t __gettext 0001b290 W dcgettext 0001bc70 W dgettext 0001bca0 W gettext definitiv in der libc selbst enthalten. Die Abhaengigkeit auf libintl ist also flacsh. Den .spec/configure/Makefile Kram von gs kenne ich jetzt nicht (aber normal sollte configure sowas "konfigurieren"), an deiner Stelle wuerde ich (wie "uebel" auch immer, die Abhaengigkeit auf die libintl einfach entfernen (.spec: 'Require:', Makefile/configure: 'LDFLAGS' vermutlich)... Und wie Suse das rpm baeckt ist mir auch ein Raetsel (Philipp, Thorsten: any Hints?), aber mir waere das ehrlich gesagt egal ;) *eg* Wie diesen Monat schonmal bemerkt: ein rpm --rebuild ohne vorher in .spec zu schauen kann unangenehm werden... -dnh PS: Zumindest Teile von # requiredforbuild sind meist ueberfluessig ;) Ich konnte noch jedes RPM auf meine zugegeben "build-system" backen, nachdem ich das komplett geloescht hatte... Ok, ein "Build-System" braucht man dafuer schon (xlibs, usw.), fuer die Doku den SGML/Jade Kram... Aber sonst? Ich loesche i.d.R. den requiredforbuild-Kommentar kommentarlos (pun intended) ;) Und IMO (siehe neulich) ist es leichtsinnig ein RPM ohne Kontrolle des .spec zu kompilieren. Und natuerlich baeckt man das RPM als user und nicht als root -- schon allein, damit einen Bugs im .spec/Makefile (wie bei kinternet) nicht das System versauen... Ein 'ginstall ... libfoo /lib/libfoo': Permission denied ist doch eher angenehm, als das dann auf einmal eine lib nicht mehr tut (ok, bei /lib/libc.so.6 lag ich faslch mit meiner Erinnerung, aber der Effekt den eine "auf einmal" beim rpm-backen ueberschriebene libc hat ist doch _sehr_ lehrreich -- und ganz und gar nicht einfach zu beheben... :) Also Kinners, Finger weg vom libc flasch kompilieren, wenn ihr nicht wisst wie ihr euer um eine funktionierende libc beraubtes System reparieren koennt -- und ja, quasi _alles_ braucht die libc... (ja, wie gesagt, das SuSE-.spec scheint es doch richtig zu machen! aber man sollte trotzdem wissen, wie man sich ggfs. "retten" kann!) -- WANTED: Schroedingers Cat, dead or alive.
participants (3)
-
Andreas Kyek
-
David Haller
-
Jochen Burkhard