[OpenAFS-devel] openafs linux-kernelmodule not buildable on sparc

[Marcus Watts]

"Daniel J. Priem" <daniel@flexserv.de> writes:
> To: openafs-devel@openafs.org
> From: "Daniel J. Priem" <daniel@flexserv.de>
> Subject: [OpenAFS-devel] openafs linux-kernelmodule not buildable on sparc
> Sender: openafs-devel-admin@openafs.org
> Date: Sat, 24 Feb 2007 08:11:46 +0100
> 
> Hi,
> i ve tried to build a linux (2.6.18 to 2.6.20) openafs-kernelmodul(tried
> from openafs 1.3 - 1.4.3-rc2) This always breaks with:
> FATAL: modpost: GPL-incompatible module libafs.ko uses GPL-only symbol
> 'sys_call_table'
> On i386 i've no problems, it's absolut sparc specific (not sure what
> will happen on ppc64)
> In Linux modpost.c is a check which does breaks if a non-gpl modue
> request a GPL-only symbol. So now i need a solution.
> One solution is to disable the check inside modpost.c, but then i am
> required to always build my own kernels. I am no longer able to run
> distribution specific kernel. Have somebody a fix for openafs, which
> solves this problem in an other(better) way?
> 
> Regards
> Daniel

When you say "distribution" - do you mean "as distributed by kernel.org"
or "as distributed by <3rd party distributor X>?"

Is there any particularly reason you want to run linux & not solaris?

Is ppc64 linux important to you?

You may also want to try openafs 1.5.15.  It is less
conservative than the 1.4 series so might have improvements that
haven't made it into 1.4 yet.

If you want to experiment, find the line in 
src/afs/LINUX/osi_probe.c that says "extern SYSCALLTYPE sys_call_table[] __attribute__((weak));
"
and replace this with some other line, say
#define sys_call_table ((SYSCALLTYPE*)0)
or perhaps
static SYSCALLTYPE sys_call_table[1];
or possibly
extern SYSCALLTYPE sys_call_table[] __attribute__((weak, alias("__this_symbol_should_not_exist__")));
this should turn off the weak reference to sys_call_table that libafs.ko is
probably making in your environment.  With luck, the other logic in osi_probe
should then find sys_call_table some other way.  This is not a "Better" way,
but it may be the best the linux developers will provide.

				-Marcus Watts