I'm running ppc profile on a ppc64 machine. When emerging mozilla/firefox the ppc64 use flag was not set so the patch "205_ppc64_mozilla-1.7.6- ppc64.patch.bz2" was not applied, but the `uname -m` actually reports the architecture is ppc64 so the mozilla/security/nss/lib got compiling error since the unpatched source only work with ppc. I think apply the patch by both ppc and ppc64 or even despite the platform is ok, since the patch has no effect to other platform specific codes. Both mozilla and firefox's affected, maybe thunderbird as well. Reproducible: Always Steps to Reproduce: 1. set make.profile link to ppc profile on a ppc64 platform. 2. emerge mozilla or firefox 3. Actual Results: security/nss/lib compiling error Expected Results: compile cleanly. Portage 2.0.52-r1 (default-linux/ppc/2005.1/ppc, gcc-3.4.4, glibc-2.3.5-r1, 2.6.13-gentoo-r2 ppc64) ================================================================= System uname: 2.6.13-gentoo-r2 ppc64 POWER5 (gr) Gentoo Base System version 1.12.0_pre8 ccache version 2.4 [enabled] dev-lang/python: 2.3.5, 2.4.1-r1 sys-apps/sandbox: 1.2.13 sys-devel/autoconf: 2.13, 2.59-r7 sys-devel/automake: 1.4_p6, 1.5, 1.6.3, 1.7.9-r1, 1.8.5-r3, 1.9.6 sys-devel/binutils: 2.16.1 sys-devel/libtool: 1.5.20 virtual/os-headers: 2.6.11-r2 ACCEPT_KEYWORDS="ppc ~ppc" AUTOCLEAN="yes" CBUILD="powerpc-unknown-linux-gnu" CFLAGS="-O2 -mtune=power5 -pipe" CHOST="powerpc-unknown-linux-gnu" CONFIG_PROTECT="/etc /usr/kde/2/share/config /usr/kde/3.5/env /usr/kde/3.5/share /config /usr/kde/3.5/shutdown /usr/kde/3/share/config /usr/lib/X11/xkb /usr/lib/ mozilla/defaults/pref /usr/share/config /var/qmail/control" CONFIG_PROTECT_MASK="/etc/env.d /etc/gconf /etc/init.d /etc/terminfo /etc/texmf/ web2c /usr/lib/X11/xkb /etc/env.d" CXXFLAGS="-O2 -mtune=power5 -pipe" DISTDIR="/usr/portage/distfiles" FEATURES="autoconfig ccache digest distlocks sandbox sfperms strict" GENTOO_MIRRORS="http://mirror.pacific.net.au/linux/Gentoo http://mirror.averse.net/pub/gentoo http://mirror.datapipe.net/pub/" LANG="zh_CN.GBK" MAKEOPTS="-j1" PKGDIR="/usr/portage/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="/usr/local/portage" SYNC="rsync://rsync.gentoo.org/gentoo-portage" USE="ppc X alsa arts bash-completion berkdb bitmap-fonts cdr cjk crypt cscope cups dbus dvd eds emboss esd fam fortran gif gnome gpm gstreamer gtk gtk2 hal ibm imagemagick ipv6 java jpeg jpeg2k kde kdeenablefinal ldap libwww mad mng motif mozilla mp3 mpeg ncurses nls nptl nptlonly ogg oggvorbis opengl pam pdflib perl png pnp python qt readline samba slang ssl tcpd tetex tiff tls truetype truetype-fonts type1-fonts unicode usb vorbis xine xml2 xv zlib userland_GNU kernel_linux elibc_glibc" Unset: ASFLAGS, CTARGET, LC_ALL, LDFLAGS, LINGUAS
Hmm, first time you tried it now? As it was also with 'use ppc64' in the older ebuilds ...
Yes I know it was "use ppc64" in old ebuilds. I was just going to file the bug and the ebuilds switch to the patch tarball, so I talk about the new patch in the bugzilla. Any reason stop it from been applied by ppc keyword?
Hmm, it was for ppc64 only, and it tweaks endianness and type sizes, so I'd rather check with the ppc guys if that is fine for ppc64 with 32bit userland. Anybody on ppc64 team care to comment?
Not sure if normal ppc team care about this.
Thanks, I saw Michael Hanselmann's fix went into mozilla&firefox ebuild, but I think that fix may still need polish. I'm using the ppc(profiles/default-linux/ppc/2005.1/ppc) profile on ppc64, not the ppc64 32-bit userland(profiles/default-linux/ppc/2005.1/ppc64/32bit-userland) on ppc64, the fix will takes care of the later one but not mine. I suggest to make this change: - if use ppc && [[ "${PROFILE_ARCH}" == ppc64 ]]; then + if use ppc && [[ `uname -m` == ppc64 ]]; then Because ${PROFILE_ARCH} is only defined in ppc64 32-bit userland profile, I changed it to use `uname -m` instead. Then I re-emerge firefox, success.
It's fine from a ppc32 standpoint, I have no idea about ppc32 UL on a ppc64 machine though.
(In reply to comment #5) > Thanks, I saw Michael Hanselmann's fix went into mozilla&firefox ebuild, but I > think that fix may still need polish. I'm using the > ppc(profiles/default-linux/ppc/2005.1/ppc) profile on ppc64, not the ppc64 > 32-bit userland(profiles/default-linux/ppc/2005.1/ppc64/32bit-userland) on > ppc64, the fix will takes care of the later one but not mine. I suggest to make > this change: > > - if use ppc && [[ "${PROFILE_ARCH}" == ppc64 ]]; then > + if use ppc && [[ `uname -m` == ppc64 ]]; then > > Because ${PROFILE_ARCH} is only defined in ppc64 32-bit userland profile, I > changed it to use `uname -m` instead. Then I re-emerge firefox, success. > I am not too keen on this, give me a few days to think on it.
(In reply to comment #5) > Thanks, I saw Michael Hanselmann's fix went into mozilla&firefox ebuild, but I > think that fix may still need polish. I'm using the > ppc(profiles/default-linux/ppc/2005.1/ppc) profile on ppc64, not the ppc64 > 32-bit userland(profiles/default-linux/ppc/2005.1/ppc64/32bit-userland) on > ppc64, the fix will takes care of the later one but not mine. I suggest to make > this change: > > - if use ppc && [[ "${PROFILE_ARCH}" == ppc64 ]]; then > + if use ppc && [[ `uname -m` == ppc64 ]]; then > > Because ${PROFILE_ARCH} is only defined in ppc64 32-bit userland profile, I > changed it to use `uname -m` instead. Then I re-emerge firefox, success. > What is the reason you can not use the 32bit userland profile?
using `uname` in an ebuild is never acceptable applying conditional patches is highly discouraged the problem you describe doesnt make any sense ... the only thing that should care that you're running on 64bit is the kernel, and firefox certainly does not qualify as kernel space
using a ppc profile instead of a ppc64/32bit profile is just wrong. also the patch has been applied upstream and is in firefox 2.0. and the mentioned patch is no longer in the patch tarball either. marking bug as INVALID.
closing
it doesnt matter, `uname -m` is wrong so fix it
no `uname -m` any more in ebuild.