glib build error

[flk]

Hallo Seife,

ich wollte gerade glib bauen und bekomme diesen Fehler:

Code: Alles auswählen

make[5]: Betrete Verzeichnis '/home/flk/build/buildsystem-cs/build_tmp/glib-2.32.4/gobject'
  CC     libgobject_2_0_la-gatomicarray.lo
  CC     libgobject_2_0_la-gbinding.lo
  CC     libgobject_2_0_la-gboxed.lo
  CC     libgobject_2_0_la-gclosure.lo
  CC     libgobject_2_0_la-genums.lo
  CC     libgobject_2_0_la-gmarshal.lo
  CC     libgobject_2_0_la-gobject.lo
  CC     libgobject_2_0_la-gparam.lo
  CC     libgobject_2_0_la-gparamspecs.lo
  CC     libgobject_2_0_la-gsignal.lo
  CC     libgobject_2_0_la-gsourceclosure.lo
  CC     libgobject_2_0_la-gtype.lo
  CC     libgobject_2_0_la-gtypemodule.lo
  CC     libgobject_2_0_la-gtypeplugin.lo
  CC     libgobject_2_0_la-gvalue.lo
  CC     libgobject_2_0_la-gvaluearray.lo
  CC     libgobject_2_0_la-gvaluetransform.lo
  CC     libgobject_2_0_la-gvaluetypes.lo
  CCLD   libgobject-2.0.la
  CC     gobject-query.o
  CCLD   gobject-query
/home/flk/build/buildsystem-cst/cross/arm-cx2450x-linux-gnueabi/bin/../lib/gcc/arm-cx2450x-linux-gnueabi/4.7.2/../../../../arm-cx2450x-linux-gnueabi/bin/ld: warning: libffi.so.6, needed by ./.libs/libgobject-2.0.so, not found (try using -rpath or -rpath-link)
./.libs/libgobject-2.0.so: undefined reference to `ffi_type_pointer'
./.libs/libgobject-2.0.so: undefined reference to `ffi_type_float'
./.libs/libgobject-2.0.so: undefined reference to `ffi_type_void'
./.libs/libgobject-2.0.so: undefined reference to `ffi_type_sint64'
./.libs/libgobject-2.0.so: undefined reference to `ffi_prep_cif'
./.libs/libgobject-2.0.so: undefined reference to `ffi_type_uint32'
./.libs/libgobject-2.0.so: undefined reference to `ffi_type_double'
./.libs/libgobject-2.0.so: undefined reference to `ffi_call'
./.libs/libgobject-2.0.so: undefined reference to `ffi_type_sint32'
./.libs/libgobject-2.0.so: undefined reference to `ffi_type_uint64'
collect2: error: ld returned 1 exit status
make[5]: *** [gobject-query] Fehler 1

libffi wurde aber gebaut und libffi.so.6 ist auch in root/lib/ vorhanden. Wo klemmts da ?

[seife]

Welche plattform? Was steht in deiner config?

Offenbar hast du dir ja ein eigenes Crosstool gebaut -- ich würde sagen das ist nicht richtig gemacht worden, drum gehts jetzt nicht.

Jup, bei mir baut's.

[flk]

Stimmt, ich habe mit Crosstool 1.18.0 gebaut. Das verwende ich aber schon eine ganze Weile und ansonsten habe ich damit noch keine Fehler bemerken können.
Ich habe diese configs verwendet.

crosstool.config.tar.gz

Die für Apollo ist ungetestet, dafür habe ich keine Hardware. Durchgebaut hatte es jedenfalls.

Wäre ich jetzt nicht sofort drauf gekommen, dass das daran liegt. Ich bau nochmal mit Crosstool 1.16.0 , dann sollte es ja gehen.

Danke

PS:
Plattform war übrigens coolstream und in der config sind die Angaben zum crosstool auskommentiert.

[seife]

naja, aber du baust halt in /home/.../buildsystem-cs, dein crosstool liegt aber in /home/.../buildsystem-cst, irgendwie muss das ja da hingekommen sein. Evtl. ist dein crosstool nicht richtig für relative Pfade konfiguriert oder so. Oder es sucht seine libs an der falschen stelle.

Jedenfalls habe ich es heute noch mal gebaut und es funktioniert.

Dieses "Apollo"-Zeug ist ja eh anders, dort nutzen die doch die uclibc, oder? Das ist in meinem Buildsystem nicht supported (und ich glaube vor ich noch eine Plattform drantackere, steige ich lieber wirklich auf openembedded / yocto um )

[flk]

Achso, ich habe mein bs eigentlich in buildsystem-cst, aber weil ich da schon so viel dran geschraubt habe und sicher sein wollte, dass durch meine Änderungen nicht irgendwas kaputt gegangen ist, habe ich, bevor ich das log gepostet habe zuerst nochmal dein bs neu ausgecheckt und dann einfach das cross Verzeichnis nach buildsystem-bs gelinkt ... daher kommt das. Geht aber mit beiden nicht. Ist auch nicht dramatisch, weil alles was ich brauch funktioniert ja, und ein Fehler im bs ist es ja anscheinend auch nicht. Ich teste das mal gelegentlich mit dem crosstool 1.16.0 und deiner config.

Mit uclibc config konnte ich zumindest Pakete für Apollo bauen, Neutrino hat zwar nicht gebaut, gab damals noch keine libs dafür im Coolstream Git, aber ansonsten ging fast alles. Habe das nicht weiter verfolgt, weil ich eh nichts testen konnte. In der config müsste gcc auf jeden Fall noch auf 4_5_3 gestellt werden. Habe gelesen, dass Neutrino ansonsten nicht starten soll.

Das ist erst mal ein Grund bei nevis zu bleiben, ich mag dein bs.

[flk]

Ich habe mir das heute nochmal angeschaut. Wenn ich das Crosstool 1.16.0 aus deinem BS verwende, geht das mit Ubuntu in Virtualbox auch nicht. Die einzige Änderung in der crosstool-ng-coolstreamnew.config war:

Code: Alles auswählen

- CT_CC_STATIC_LIBSTDCXX is not set
+CT_CC_STATIC_LIBSTDCXX=y

Ansonsten baut das unter Ubuntu nicht durch.

Wenn ich das Crosstool aber unter Archlinux baue, funtioniert das auch mit glib. Anscheinend also ein Ubuntu spezifisches Problem.

[seife]

Baut dann die glib nicht oder baut das crosstool gleich gar nicht?
Das mit dem CT_CC_STATIC_LIBSTDCXX beim crosstool war irgendein fehlendes -devel paket glaube ich, ich weiss aber nicht mehr welches. Bei Arch sind ja immer die devel-pakete mit installiert, drum klappts dort ;-)

[doc]

Ne das ist beim Bauen der glib. Das Problem ist eher das was der Compiler bzw. der Linker bemeckert, die Libs für libffi werden nicht gefunden. Dazu würde ich den Aufruf vom make Target mal von Hand nachstellen und dann mit den Angaben spielen (-lffi -L<ffi_libs_path> bzw. LIBFFI_CFLAGS). Was Du genau benutzen muss sagt Dir ein Blick ins Makefile. Beim Makeaufruf sollte ein "V=1 make [foo]" auch etwas mehr Output liefern können.

[seife]

aber warum das mit CT_CC_STATIC_LIBSTDCXX=yes funktioniert ist mir ein Rätsel...

[flk]

Ohne "CT_CC_STATIC_LIBSTDCXX=y" baut bei Ubuntu die Crosstool gar nicht, bricht beim gcc build ab. Aber glib kriege ich mit Ubuntu überhaupt nicht gebaut. Archlinux hat da weniger Probleme, da brauch ich das "CT_CC_STATIC_LIBSTDCXX=y" nicht, die Crosstool baut ohne Anpassung durch. Aber auch wenn "CT_CC_STATIC_LIBSTDCXX=y" gesetzt ist, baut mir Arch die Crosstool und auch glib. Dafür habe ich da bei manchen Paketen schlimmen Ärger mit libtool. Da werden die libs zuerst in /usr/lib vom Host gesucht. Ist dort die entsprechende lib vorhanden gibts Mecker, ansonsten nimmt er die aus sys-root. Libupnp oder Streamripper sind z.B solche Fälle.

Das Problem ist hier ganz gut beschrieben:

http://lists.debian.org/debian-devel/20 ... 00196.html

[flk]

Ne das ist beim Bauen der glib. Das Problem ist eher das was der Compiler bzw. der Linker bemeckert, die Libs für libffi werden nicht gefunden. Dazu würde ich den Aufruf vom make Target mal von Hand nachstellen und dann mit den Angaben spielen (-lffi -L<ffi_libs_path> bzw. LIBFFI_CFLAGS). Was Du genau benutzen muss sagt Dir ein Blick ins Makefile. Beim Makeaufruf sollte ein "V=1 make [foo]" auch etwas mehr Output liefern können.

Werde ich die Tage mal ausprobieren. Mal sehen wie weit ich komme

[seife]

Wenn die crosstoolchain ohne static-libstdc++ nicht baut fehlt ein develpaket. Welches weiss ich nicht mehr, aber das sollte sich rausfinden lassen.

[flk]

Ich habe heute versucht, die glib von Hand cross zu kompilieren, habe aber aufgegeben, weil ich schon ungefähr ne dreiviertel Stunde damit verbracht hatte, Tests zu deaktivieren und dann immer noch bei configure festgehangen bin ... ist mir Ubuntu dann doch nicht wert. Das war eh nur ein Notbehelf, weil mein Archlinux beim Bauen solche Zicken gemacht hat.
Durch den obigen Beitrag aus der Debian List bin ich aber auf die Idee gekommen, dass meine Archlinux Probleme durch eine i386 Installation behoben werden könnten, und so war s dann auch. Mit Archlinux in 32 bit in der VM funktioniert alles wie es soll. Das Problem mit der statischen libstdc hat sich somit nebenbei auch erledigt

[seife]

dann hast du im 64-bit arch eine config.site die dazwischenfunkt -- irgendwo in /usr/share/automake oder so.

Wenn man das richtig machen wollte, müsste man auch ein eigenes autoconf/automake/libtool bauen, was eben nie in /usr schaut, so wie ich es mit pkg-config schon mache. Aber wenn man das alles richtig machen will, dann kann man gleich einfach openembedded oder yocto verwenden, da ist das alles schon drin