[OpenAFS-devel] Re: Compiling openafs on arm64/aarch64 architecture

[Benjamin Kaduk]

On Thu, 4 Sep 2014, Micheal Waltz wrote:

> The userspace build for the most part was successful (src/lwp/rw was not built
> to test), but it fails on building the libafs Linux kernel module with:

I think you can make rw manually by cd-ing to src/lwp and running 'make
rw'.

> /home/mwaltz/git/openafs/src/libafs/MODLOAD-3.13.0-34-generic-MP/afs_vnop_flock.c:137:1:
> error: conflicting types for 'lockIdSet'
>
> I looked into this issue, but got stuck and am not really sure how to proceed.
> I think it may have to do with some CCFLAGS/DEFINES in
> src/libafs/MakefileProto.LINUX.in for the arm64_linux26 sysname, but I don't
> know what flags may be needed. Other threads on the openafs-devel list from
> the past show it could be something with not copying required objects
> correctly.
>
> Does anyone have any pointers here? Also, is there an easy way to just try and
> re-build just the module without having to start the entire compile over
> again? It takes 1-2 hours on an emulated VM to get to this stage and is very
> time consuming. Thank you.
>
>
> Full compile error, only "./configure; make" was used to build, no additional
> flags:

>From a quick skim, all of the errors seem to be due to a missing
definition for struct AFS_FLOCK in this scope.  That's a bit confusing.
Looking at where AFS_FLOCK is defined as a preprocessor macro in
src/afs/afs.h, it looks like you may be getting the 'flock64' define
instead of 'flock', since AFS_LINUX_64BIT_KERNEL is not defined in your
param.arm64_linux26.h.  I would try adding that (and maybe seeing if there
are similar things missing, by comparing the amd64, i386, and arm versions
of those config headers), and attempting again to build.

After a config header change like that, you will need to rebuild all of
the objects used for the kernel module, but not necessarily everything
else.  IIRC, our linux kernel module build process will rebuild everything
every time anyway, so you should be able to just 'make config && cd
src/libafs && make libafs' for the minimal-work rebuild attempt.  ('make
config' is needed to regenerate the config.h, it looks like.)

Also, I think that a bare ./configure is generally disrecommended, though
it may be appropriate here for bringing up a new platform.  I tend to
build with at least --enable-warnings and --enable-debug and
--enable-debug-kernel; --enable-checking is another one that is
developer-friendly.  I forget how those are implemented and whether that
implementation means some of them will be no-ops on a new platform,
though.

-Ben