i dont see why this is arch specific, but ignoring that issue, the tools are run in the wrong order: if useq amd64 || useq ppc64; then aclocal -I scripts automake -c -f autoconf libtoolize --copy --force fi code should either be dropped, or fixed and run on all architectures ...
looks like that isnt the only package ... gnome-vfsmm libgnomecanvasmm libgnomemm libgnomeuimm
I remember those packages failing on ppc64 (if it was configure or compiling I don't remember). I saw that amd64 did those autotool handling tried it and it worked, so I added ppc64 to the list of archs doing this. I will check if newer versions still need this.
ok. gconfmm-2.6.1 fails like this, if we don't do the auto* thing: /usr/lib/gcc/powerpc64-unknown-linux-gnu/4.1.1/../../../../lib64/crti.o: In function `_init': /var/tmp/portage/glibc-2.4-r3/work/build-ppc64-powerpc64-unknown-linux-gnu-nptl/csu/crti.S:(.opd+0x18): multiple definition of `_init' /usr/lib/gcc/powerpc64-unknown-linux-gnu/4.1.1/../../../../lib64/crti.o:/var/tmp/portage/glibc-2.4-r3/work/build-ppc64-powerpc64-unknown-linux-gnu-nptl/csu/crti.S:(.opd+0x18): first defined here /usr/lib/gcc/powerpc64-unknown-linux-gnu/4.1.1/../../../../lib64/crti.o: In function `_fini': /var/tmp/portage/glibc-2.4-r3/work/build-ppc64-powerpc64-unknown-linux-gnu-nptl/csu/crti.S:(.opd+0x30): multiple definition of `_fini' /usr/lib/gcc/powerpc64-unknown-linux-gnu/4.1.1/../../../../lib64/crti.o:/var/tmp/portage/glibc-2.4-r3/work/build-ppc64-powerpc64-unknown-linux-gnu-nptl/csu/crti.S:(.opd+0x30): first defined here /usr/lib/gcc/powerpc64-unknown-linux-gnu/4.1.1/crtbeginS.o:(.data.rel+0x0): multiple definition of `__dso_handle' /usr/lib/gcc/powerpc64-unknown-linux-gnu/4.1.1/crtbeginS.o:(.data.rel+0x0): first defined here collect2: ld returned 1 exit status Newer versions don't need the auto* stuff. I'll go through the packages and check if they still need this on ppc64 or not.
ppc64 done. tested all newer versions and removed ppc64 from the archs doing the auto* stuff as they are no longer required.
that works for the 2.6 SLOTs, but the 1.0 SLOTs are still screwy
yes, I didn't removed ppc64 from the list of arches doing the auto* stuff, because it failed similar to comment #3. You said that the auto* stuff is done in the wrong order. So I should fix the order?
if that stuff is truly still needed, you should inherit autotools and run 'eautoreconf' it should also not be conditional on $ARCH
vapier: if autoheader from eautoreconf fails like seen below, I would use eaclocal, eautoconf, eautomake from autotools.eclass and elibtoolize from libtool.eclass. Is this correct? ***** autoheader ***** autoheader-2.59: warning: missing template: GCONFMM_MAJOR_VERSION autoheader-2.59: Use AC_DEFINE([GCONFMM_MAJOR_VERSION], [], [Description]) autoheader-2.59: warning: missing template: GCONFMM_MICRO_VERSION autoheader-2.59: warning: missing template: GCONFMM_MINOR_VERSION
fixed in the newest revisions of the ebuilds. I will wait to close this until they are stable with 2.16.
We are stable with 2.16. I believe this can be closed.
(In reply to comment #10) > We are stable with 2.16. I believe this can be closed. Nope, this is not fixed in current 2.12.x stable ebuilds; we need to stabilize dev-cpp/{libgnomemm,libgnomeuimm,libgnomecanvasmm}-2.16.0 (dev-cpp/gnome-vfsmm-2.16.0 already is stable).
(In reply to comment #11) > Nope, this is not fixed in current 2.12.x stable ebuilds; we need to stabilize > dev-cpp/{libgnomemm,libgnomeuimm,libgnomecanvasmm}-2.16.0 > (dev-cpp/gnome-vfsmm-2.16.0 already is stable). Newer versions have been stabled on all arches. Closing.
