This doesnt compile as it is hard coded into the ebuild. I am fixing this (and other sparc64 openafs problems) and will submit a fixed .ebuild file I can only test on sparc64.
I've been working to get openafs running on Alpha. Here's a comprehensive list of the problems so far: -all versions of openafs in portage are hard coded for x86 -any version of openafs I have tried (1.2.8, 1.2.9_rc2, 1.3.2) will not compile with gcc 3.2.x and maybe 3.x.x. I went back to gcc 2.95.3, which yeilds successful openafs compiles. The kernel and the rest of the system may be compiled with 3.2.x. -gcc 2.95.3 in portage will not emerge on alpha. The patches applied break the compile. I created an ebuild that does not apply these patches. -openafs version =<1.2.8 will not compile with the newer glibc. 1.2.9_rc2 works great (with gcc 2.95.3) I've hacked up the openafs-1.2.8 ebuild to create an openafs-1.2.9_rc2 ebuild, attached above. I have only tested on alpha and x86, so I cannot speak for sparc. Perhaps someone else can make any necessary changes and repost it here. How do we go about getting the ebuilds in portage corrected? Jacob Joseph AUTON Lab (www.autonlab.org) Carnegie Mellon University
Created attachment 10115 [details] openafs-1.2.9_rc2.ebuild This ebuild is far from a polished, production piece of work. It is intended only to fix the problems I have encountered in getting openafs to run on the Alpha platform. It should work on x86 as well. BTW, where do I find a formatting guide for the header?
I've tried getting openafs to build with and without your ebuild modifications but no luck. I'm thinking this is a vendor bug, but if anyone with more C debugging knowledge wants to take a crack at it by all means.
Created attachment 16233 [details, diff] patch for openafs-1.2.10.ebuild This patch allows openafs-1.2.10.ebuild to merge correctly on x86 without explicitly setting the AFS sysname to i386_linux24. It may allow 1.2.10 to build correctly on non-x86 architectures as well.
The patch seems to have fixed the place where it was dying before, but it still dies. More info below gcc -O2 -fomit-frame-pointer -fno-strength-reduce -fno-strict-aliasing -fno-co mmon -pipe -mcpu=v8 -mno-fpu -fcall-used-g5 -fcall-used-g7 -D__KERNEL__ -DCPU=s parc -DKERNEL -D_KERNEL -DMODULE -I. -I../ -I/var/tmp/portage/openafs-1.2.10/wo rk/openafs-1.2.10/src/config -c ../afs/afs_analyze.c; In file included from ../asm/string.h:12, from ../h/string.h:25, from ../afs/stds.h:191, from ../afs/afs_sysnames.h:27, from ../afs/param.h:51, from ../afs/afs_analyze.c:14: ../asm/page.h:57:1: warning: "clear_user_page" redefined In file included from ../linux/modversions.h:266, from ../afs/param.h:47, from ../afs/afs_analyze.c:14: ../linux/modules/sparc64_ksyms.ver:208:1: warning: this is the location of the p revious definition In file included from ../asm/string.h:12, from ../h/string.h:25, from ../afs/stds.h:191, from ../afs/afs_sysnames.h:27, from ../afs/param.h:51, from ../afs/afs_analyze.c:14: ../asm/page.h:58:1: warning: "copy_user_page" redefined In file included from ../linux/modversions.h:266, from ../afs/param.h:47, from ../afs/afs_analyze.c:14: ../linux/modules/sparc64_ksyms.ver:210:1: warning: this is the location of the In file included from ../afs/sysincludes.h:65, from ../afs/afs_analyze.c:19: ../asm/uaccess.h:304:1: warning: "__copy_to_user" redefined In file included from ../linux/modversions.h:266, from ../afs/param.h:47, from ../afs/afs_analyze.c:14: ../linux/modules/sparc64_ksyms.ver:226:1: warning: this is the location of the In file included from ../afs/sysincludes.h:65, from ../afs/afs_analyze.c:19: ../asm/uaccess.h:318:1: warning: "__copy_from_user" redefined In file included from ../linux/modversions.h:266, from ../afs/param.h:47, from ../afs/afs_analyze.c:14: ../linux/modules/sparc64_ksyms.ver:228:1: warning: this is the location of the In file included from ../linux/fs.h:299, from ../linux/capability.h:17, from ../linux/binfmts.h:5, from ../linux/sched.h:9, from ../asm/uaccess.h:11, from ../afs/sysincludes.h:65, from ../afs/afs_analyze.c:19: ../linux/ext3_fs_i.h:75: field `truncate_sem' has incomplete type In file included from ../linux/capability.h:17, from ../linux/binfmts.h:5, from ../linux/sched.h:9, from ../asm/uaccess.h:11, from ../afs/sysincludes.h:65, from ../afs/afs_analyze.c:19: ../linux/fs.h:464: field `i_alloc_sem' has incomplete type ../linux/fs.h:526: confused by earlier errors, bailing out make[4]: *** [afs_analyze.o] Error 1 make[4]: Leaving directory `/var/tmp/portage/openafs-1.2.10/work/openafs-1.2.10' make[3]: *** [linux_compdirs] Error 2 make[3]: Leaving directory `/var/tmp/portage/openafs-1.2.10/work/openafs-1.2.10' make[2]: *** [libafs] Error 2 make[2]: Leaving directory `/var/tmp/portage/openafs-1.2.10/work/openafs-1.2.10' make[1]: *** [build] Error 2 make[1]: Leaving directory `/var/tmp/portage/openafs-1.2.10/work/openafs-1.2.10' make: *** [all] Error 2 !!! ERROR: net-fs/openafs-1.2.10 failed. !!! Function src_compile, Line 45, Exitcode 2 !!! (no error message)
Does configure set the AFS_SYSNAME in the top-level Makefile correctly? Can you compile successfully from the tarball (not using the ebuild)? I have only x86 hardware, so I'm flying blind.
Via the ebuild, the SYS_NAME is hardcoded to i386_linux24 On sparc64 Compiling by hand changes SYS_NAME to sparc64_linux24 However, while openafs does compile a little farther than before, it still dies. I'm guessing this is due to the fact it needs to compile kernel modules, and we are still using egcs as the kernel compiler on sparc64. On sparc32 openafs compiles fine by hand on sparc. What I will do for now is add the ~sparc keyword to openafs-1.2.10.ebuild, fix the econf options to use the right afs-sys-name for sparc32 and then package mask it for sparc64, so it will only build on sparc32 machines. Also marking package as dependent on bug #24631 as I'm guessing that's what will allow it to work on sparc64.
The patch I submitted to the ebuild above (16233) lets configure choose the AFS_SYSNAME, and then greps it out of the Makefile for installing. Doesn't that work on sparc? (It's ugly, but it should work.) Good input on the sparc64 problems. Those errors don't look ebuild-related.
Oh, I totally didn't see that. I applied the patch and sparc32 builds right out of the box. I don't have a setup of openafs at the moment to see if it's working correctly or not. I'll try to get something up in the next day or two to confirm.
I'm about to attach a new openafs ebuild to this bug that enables multiple architectures. It should work on alpha, ia64, ppc, sparc, sparc64 and x86. I am marking it KEYWORDS="~x86 ~alpha ~ia64" since those are the platforms on which I can test build. The following tasks remain for this bug: (1) Ryan needs to either commit it or let me do it. (2) The other arches should test it and add their keywords as appropriate.
Created attachment 23705 [details] openafs-1.2.10-r2.ebuild
Okay, openafs-1.2.10-r2.ebuild is committed. ppc and sparc, please test build and add your keywords. By the way, the only thing I can envision going wrong with this is that it's possible that the kernel modules won't work with -fPIC. I don't have any reason to believe this would be the case, I just figure it's a possibility. So if things don't work, that's something to investigate.
Comment from Jason Wever on #gentoo-dev: <@Weeve> agriffis: last time i tried testing it, the modules wouldn't load, and it won't work at all on sparc64 until we get 64 bit binary support in there. Basically we need somebody to test the 1.2.10-r2 ebuild in portage and tell us if it works, then we'll add ~sparc and/or ~ppc
I'm getting stuck at the same point as Weeve above, in afs_analyze.c but with less warnings/errors. AFS_SYSNAME is sparc_linux24. gcc -fPIC -O2 -fomit-frame-pointer -fno-strength-reduce -fno-strict-aliasing -fno-common -pipe -mcpu=v8 -mno-fpu -fcall-used-g5 -fcall-used-g7 -D__KERNEL__ -DCPU=sparc -DKERNEL -D_KERNEL -DMODULE -DAFS_SMP -I. -I../ -I/var/tmp/portage/openafs-1.2.10-r2/work/openafs-1.2.10/src/config -c ../afs/afs_analyze.c; In file included from ../linux/fs.h:299, from ../linux/capability.h:17, from ../linux/binfmts.h:5, from ../linux/sched.h:9, from ../asm/uaccess.h:11, from ../afs/sysincludes.h:65, from ../afs/afs_analyze.c:19: ../linux/ext3_fs_i.h:75: field `truncate_sem' has incomplete type In file included from ../linux/capability.h:17, from ../linux/binfmts.h:5, from ../linux/sched.h:9, from ../asm/uaccess.h:11, from ../afs/sysincludes.h:65, from ../afs/afs_analyze.c:19: ../linux/fs.h:464: field `i_alloc_sem' has incomplete type ../linux/fs.h:526: confused by earlier errors, bailing out make[4]: *** [afs_analyze.o] Error 1 Compiling by hand breaks differently: sparc64-linux-gcc -O2 -fomit-frame-pointer -fno-strength-reduce -fno-strict-aliasing -fno-common -pipe -mcpu=ultrasparc -m64 -mno-fpu -mcmodel=medlow -ffixed-g4 -fcall-used-g5 -fcall-used-g7 -Wno-sign-compare -D__KERNEL__ -DCPU=sparc64 -DKERNEL -D_KERNEL -DMODULE -DAFS_SMP -I. -I../ -I/root/openafs-1.2.10/src/config -c ../afs/afs_analyze.c; In file included from ../rx/rx.h:38, from ../afs/afsincludes.h:30, from ../afs/afs_analyze.c:35: ../rx/rx_packet.h:45:58: sys/sysmacros.h: No such file or directory
gustavoz, I suspect the sparc_linux24 target is for 32-bit, but in your comment it looks like you're using sparc64-linux-gcc ... is there a sparc64_linux24 target for openafs? If not, then I think you'll need to build it for 32-bit. Sorry that I don't understand all the issues around this for sparc...
The ebuild is always building a sparc32 target "sparc_linux24". Manually compiling (good old ./configure) the target is effectively "sparc64_linux24" and fails the way i showed in the second message. Dunno if OpenAFS will work as a hybrid, since sparc64 is currently 32 bit userland and 64 bit kernel...
openads-1.2.10-r2 builds on sparc32, but the module issues the following errors when loading; /etc/afs/modload/libafs-2.4.24-sparc.mp.o: unresolved symbol _do_spin_unlock_R__ver__do_spin_unlock /etc/afs/modload/libafs-2.4.24-sparc.mp.o: unresolved symbol _do_spin_lock_R__ver__do_spin_lock /etc/afs/modload/libafs-2.4.24-sparc.mp.o: unresolved symbol _GLOBAL_OFFSET_TABLE_ /etc/afs/modload/libafs-2.4.24-sparc.mp.o: unresolved symbol kernel_flag_R__ver_kernel_flag /etc/afs/modload/libafs-2.4.24-sparc.mp.o: Hint: You are trying to load a module without a GPL compatible license and it has unresolved symbols. Contact the module supplier for assistance, only they can help you.
Openafs-1.2.10-r2 fails to compile on amd64. A pach is required to change "old_gid_t" in osi_groups.c and osi_modules.c to "u16". If you do not believe me, see: https://lists.openafs.org/pipermail/openafs-info/2003-August/010342.html. Also, for reference, openafs will not compile without 32 bit emulation enabled in the amd64 kernel. This probably isn't something gentoo's going to fix, but it is very important to note, and otherwise requires much debugging. Maybe there is a reliable way we can check in the ebuild to print an error? -Jacob
Created attachment 25953 [details, diff] This substitutes old_gid_t for u16, which is needed for amd64. I have not tested this patch (yet) on x86 and alpha and currently only apply it if "${ARCH}" = "amd64". It might be that it works everywhere. -Jacob
I have that patch successfully working on x86. I have committed it to -r2. Does it work for everyone?
what the status of this?
Status is this is still broken for sparc and short of upstream intervention, probably won't be fixed. Problem isn't Gentoo related wrt sparc.
Created attachment 27824 [details, diff] openafs-sparc-1.2.11.patch This patch allows for successful compilation of openafs-1.2.11 on sparc64. Tested on sparc64 and x86. Requires above typechange patch.
Created attachment 27825 [details] openafs-1.2.11-r1.ebuild Openafs 1.2.11-r1 ebuild. Ebuild that allows for compilation of openafs 1.2.11 under sparc64 using above patch.
I've verified that hardave's patch works just fine on sparc64. The only thing holding me back from enabling this for sparc64 is that programs that use the afs useflag don't seem to be building correctly at the moment. I haven't looked into this extensively as the afs useflag is masked on sparc currently.
It says openafs does not yet support a 2.6 kernel. ppc deprecated 2.4 kernels because they are no longer maintained upstream. Any idea when 2.6 support is to be expected?
any idea on the 2.6 time frame ? pretty much all development has been moved to 2.6 and 2.4 is in maintain-only mode ... and for most non-x86 arches, 2.4 is becoming completely abandoned
The current 1.3 development tree has partial support for 2.6 on x86. I believe it does everything except cross pid PAGs. And even for that I believe you can patch kernel sources and recompile if support is needed. Other archs are not supported as of yet, but it shouldn't be too difficult to port. There is no estimated release date for 1.4.
ppc will be happy to test whenever a 1.3 ebuild is available.
still no luck it seems, openafs-1.3.82 lists the following: alpha_dux40 alpha_dux50 (only tested on 5.0A, does not work with 5.1) i386_fbsd_42, i386_fbsd_43, i386_fbsd_44, i386_fbsd_45, i386_fbsd_46, i386_fbsd_47, i386_fbsd_50, i386_fbsd_51, i386_fbsd_52, i386_fbsd_53 i386_linux22 i386_linux24 i386_linux26 x86 can pull of kernel 2.6 now i386_umlinux22 i386_umlinux24 i386_obsd31, i386_obsd32, i386_obsd33, i386_obsd34, i386_obsd35, i386_obsd36 rs_aix42 sgi_65 (file server not tested) sun4_413 (No client support, no fileserver support, db servers only) sun4x_56, sun4x_57, sun4x_58, sun4x_59 (logging UFS not supported for mixed-use partitions containing client cache) ppc_darwin_70 ppc-macos can possibly use it ppc_linux22 ppc_linux24 ppc stuck at 2.2/2.4 alpha_linux22 alpha_linux24 ditto for alpha ia64_linux24 ia64_linux26 well, ia64 seems to do ok. Makes me wonder why amd64 isn't here... sparc_linux22 sparc_linux24 sparc64_linux22 sparc64_linux24 both 64 and 32 bit sparcs are still 2.2/2.4 as well. Oh well, at least ia64 is getting noticed :). I may poke the mailing list to see what's stopping them from doing 2.6 on other linux systems.
OpenAFS needs a developer to take up maintenance.
New ebuilds for openafs 1.2.13 (stable) and 1.3.85 (experimental) are available for testing. According to openafs-ml, 1.3.85 is currently undergoing testing so it can become 1.4rc. Probably many comments in this bug are now outdated. I would be glad if the new ebuilds could be tested. Some quick maybe relevant remarks: alpha should work, sparc hasn't been tested yet, and if you're running a 2.6 kernel, you have no choice but to go for 1.3.85.
OpenAFS should work on sparc64 (with linux 2.4), though I cannot test this. Please report on your success with the latest ebuild (preferably 1.3.x, otherwise 1.2.x)
