The sys-fs/aufs3-3_p20120813 ebuild currently does not support non-x86 architectures, but from the sources it seems that aufs3 should do so. I'll gather my patches for ppc64 in this bugreport. Reproducible: Always
Created attachment 321994 [details, diff] Patch that sets ARCH properly
(In reply to comment #1) > Created attachment 321994 [details, diff] [details, diff] > Patch that sets ARCH properly P.S: This patch should be harmless and work without any trouble on x86, as it just switches from a hardcoded ARCH to the one found by toolchain-funcs.eclass.
Created attachment 322008 [details, diff] patch-0001: set ARCH for non-x86
Created attachment 322012 [details, diff] patch-0002: set_config INO_T_64 on ppc64 ino_t is 64bit large on ppc64, too. (Actually on all arches except S390 and ALPHA, according to config.mk.)
(In reply to comment #4) > Created attachment 322012 [details, diff] [details, diff] > patch-0002: set_config INO_T_64 on ppc64 > > ino_t is 64bit large on ppc64, too. P.S: I removed the check for nfs, since INO_T_64 appears like a general system property. Unrelated question: Why do you check for CONFIG_EXPERIMENTAL? That flag only appears to allow to select additional drivers/features in the Linux Kernel config, but no reference to it (i.e. optional feature / config option) appears in the aufs3 sources.
Can this be set for ARM as well? I'm seeing (from a good googling) that it's working very well on ARM systems (Arch has it built-in).
@arm How about the ino_t_64.patch? You don't need that, right?
(In reply to comment #7) > @arm > How about the ino_t_64.patch? You don't need that, right? It is needed were long (the original type of ino_t) is 64bit, except on Alpha and S390. [1] From looking at the ARM Compiler Reference long is 32bit on ARM — but I don't know about ARMv8… [1] grep -R '\<__kernel_ino_t\>' /usr/src/linux
Any progress with this?
*** Bug 433497 has been marked as a duplicate of this bug. ***
Removing dependency on the toolchain-funcs bug as it has been fixed but is staying open as a reminder to maybe give tc-arch-kernel a new home
+*aufs3-3_p20120813-r1 (07 Oct 2012) + + 07 Oct 2012; Justin Lecher <jlec@gentoo.org> +aufs3-3_p20120813-r1.ebuild: + Included patch to make the package compatible with non x86 & amd64 arches, + #432392 +
@arches, please keyword
This revbump breaks compilation on amd64 when the nfs USE flag is unset. [ebuild U ] sys-fs/aufs3-3_p20120813-r1 [3_p20120813] USE="kernel-patch -debug -doc -fuse -hfs -inotify -nfs -pax_kernel -ramfs" * Package: sys-fs/aufs3-3_p20120813-r1 * Repository: gentoo * Maintainer: jlec@gentoo.org tommy@gentoo.org * USE: amd64 elibc_glibc kernel-patch kernel_linux multilib userland_GNU * FEATURES: preserve-libs sandbox * Determining the location of the kernel source code * Found kernel source directory: * /usr/src/linux * Found kernel object directory: * /lib/modules/3.4.9-gentoo/build * Found sources for kernel version: * 3.4.9-gentoo * Checking for suitable kernel configuration options... [ ok ] >>> Unpacking source... >>> Unpacking aufs3-3_p20120813.tar.xz to /var/tmp/portage/sys-fs/aufs3-3_p20120813-r1/work >>> Source unpacked in /var/tmp/portage/sys-fs/aufs3-3_p20120813-r1/work >>> Preparing source in /var/tmp/portage/sys-fs/aufs3-3_p20120813-r1/work/aufs3-standalone ... * Using for module creation branch origin/aufs3.4 * Using for utils building branch origin/aufs3.0 Branch local-gentoo set up to track remote branch aufs3.0 from origin. Switched to a new branch 'local-gentoo' >>> Source prepared. >>> Configuring source in /var/tmp/portage/sys-fs/aufs3-3_p20120813-r1/work/aufs3-standalone ... >>> Source configured. >>> Compiling source in /var/tmp/portage/sys-fs/aufs3-3_p20120813-r1/work/aufs3-standalone ... make -j1 CC=x86_64-pc-linux-gnu-gcc ARCH=x86 CONFIG_AUFS_FS=m KDIR=/usr/src/linux config.mk:102: *** CONFIG_AUFS_INO_T_64 requires CONFIG_AUFS_EXPORT. Stop. * ERROR: sys-fs/aufs3-3_p20120813-r1 failed (compile phase): * emake failed * * If you need support, post the output of `emerge --info '=sys-fs/aufs3-3_p20120813-r1'`, * the complete build log and the output of `emerge -pqv '=sys-fs/aufs3-3_p20120813-r1'`. * The complete build log is located at '/var/tmp/portage/sys-fs/aufs3-3_p20120813-r1/temp/build.log'. * The ebuild environment file is located at '/var/tmp/portage/sys-fs/aufs3-3_p20120813-r1/temp/environment'. * Working directory: '/var/tmp/portage/sys-fs/aufs3-3_p20120813-r1/work/aufs3-standalone' * S: '/var/tmp/portage/sys-fs/aufs3-3_p20120813-r1/work/aufs3-standalone'
Thanks for the report. + 08 Oct 2012; Justin Lecher <jlec@gentoo.org> aufs3-3_p20120813-r1.ebuild: + Fix compilation if USE=-nfs, #432392 +
+ 18 Oct 2012; Justin Lecher <jlec@gentoo.org> aufs3-3_p20120813-r1.ebuild, + aufs3-3_p20121015.ebuild: + Merge changes related bugs 432346 432392 432398 into newest version +
Thanks for getting the fixes back in! There is still an issue, however: emake CC=$(tc-getCC) ... On my system (ppc64), tc-getCC produces "…-gcc -m64", which breaks above line if it is not quoted. The same goes for the various instances of KV{_OUT,}_DIR. Hence I think it would not hurt if all parameters were quoted: -emake CC=$(tc-getCC) LD=$(tc-getLD) LDFLAGS="$(raw-ldflags)" ARCH=$(tc-arch-kernel) CONFIG_AUFS_FS=m KDIR=${KV_DIR} +emake CC="$(tc-getCC)" LD="$(tc-getLD)" LDFLAGS="$(raw-ldflags)" ARCH="$(tc-arch-kernel)" CONFIG_AUFS_FS=m KDIR="${KV_DIR}" Same in line 132 and 145.
(In reply to comment #17) > Thanks for getting the fixes back in! > > There is still an issue, however: > emake CC=$(tc-getCC) ... > > On my system (ppc64), tc-getCC produces "…-gcc -m64", which breaks above is this special on your system?
(In reply to comment #18) > (In reply to comment #17) > > Thanks for getting the fixes back in! > > > > There is still an issue, however: > > emake CC=$(tc-getCC) ... > > > > On my system (ppc64), tc-getCC produces "…-gcc -m64", which breaks above > > is this special on your system? This makes no sense. It should produce "powerpc64-unknown-linux-gnu-gcc". The code from toolchain-funcs.eclass prints out $CHOST. Look around lines 58 and lines 44-45.
(In reply to comment #19) > (In reply to comment #18) > > (In reply to comment #17) > > > Thanks for getting the fixes back in! > > > > > > There is still an issue, however: > > > emake CC=$(tc-getCC) ... > > > > > > On my system (ppc64), tc-getCC produces "…-gcc -m64", which breaks above > > > > is this special on your system? > > This makes no sense. It should produce "powerpc64-unknown-linux-gnu-gcc". > The code from toolchain-funcs.eclass prints out $CHOST. Look around lines > 58 and lines 44-45. It is reproducible. Try: CC='powerpc64-unknown-linux-gnu-gcc -m64' emerge aufs3 And you will get: >>> Compiling source in /var/tmp/portage/sys-fs/aufs3-3_p20121015/work/aufs3-standalone ... make -j3 CC=powerpc64-unknown-linux-gnu-gcc -m64 'LDFLAGS=-O1 --as-needed --hash-style=gnu' ARCH=powerpc CONFIG_AUFS_FS=m KDIR=/var/kernel/build-3.6.2-gentoo make: invalid option -- '6' make: invalid option -- '4' I am not sure how this happened the first time, without me manually setting CC, but it did. It might have been the kernel makefiles setting CC, resulting in it being passed through to emerge when it was called by my postinst.d @module-rebuild hook.
Should be fixed. Having spaces in $CC is not support anywhere.
