On Thu, 2004-04-15 at 05:42, Arkadiusz Miskiewicz wrote:
> insmod: error inserting './Intel537.ko': -1 Invalid module format
They didn't use -fno-common. The patch which adds in the warning got
lost a while back.
Here's a new one...
Rusty.
Name: Print Warning for Common Symbols
Status: Trivial
People still build modules wrong, particularly without -fno-common.
The resulting modules don't load, but we should at least warn about it.
diff -urpN --exclude TAGS -X /home/rusty/devel/kernel/kernel-patches/current-dontdiff --minimal .17714-linux-2.6.5-bk2/kernel/module.c .17714-linux-2.6.5-bk2.updated/kernel/module.c
--- .17714-linux-2.6.5-bk2/kernel/module.c 2004-04-15 09:24:16.000000000 +1000
+++ .17714-linux-2.6.5-bk2.updated/kernel/module.c 2004-04-15 10:32:39.000000000 +1000
@@ -1003,6 +1003,8 @@ static int simplify_symbols(Elf_Shdr *se
/* We compiled with -fno-common. These are not
supposed to happen. */
DEBUGP("Common symbol: %s\n", strtab + sym[i].st_name);
+ printk("%s: please compile with -fno-common\n",
+ mod->name);
ret = -ENOEXEC;
break;
--
Anyone who quotes me in their signature is an idiot -- Rusty Russell
On Thu, Apr 15, 2004 at 11:52:48AM +1000, Rusty Russell wrote:
> On Thu, 2004-04-15 at 05:42, Arkadiusz Miskiewicz wrote:
> > insmod: error inserting './Intel537.ko': -1 Invalid module format
>
> They didn't use -fno-common. The patch which adds in the warning got
> lost a while back.
>
> Here's a new one...
Is it be possible to detect this during the modpost stage, or do they manage to
avoid that in some way?
I would rather see the error a bit earlier. Eventually depmod.
Still your patch make relevance as a double check.
Sam
On Thu, 2004-04-15 at 14:44, Sam Ravnborg wrote:
> On Thu, Apr 15, 2004 at 11:52:48AM +1000, Rusty Russell wrote:
> > On Thu, 2004-04-15 at 05:42, Arkadiusz Miskiewicz wrote:
> > > insmod: error inserting './Intel537.ko': -1 Invalid module format
> >
> > They didn't use -fno-common. The patch which adds in the warning got
> > lost a while back.
> >
> > Here's a new one...
>
> Is it be possible to detect this during the modpost stage, or do they manage to
> avoid that in some way?
> I would rather see the error a bit earlier. Eventually depmod.
> Still your patch make relevance as a double check.
They can only do this if they're not using the kernel makefiles. So I
don't really think it's a priority...
Cheers,
Rusty.
--
Anyone who quotes me in their signature is an idiot -- Rusty Russell
Rusty Russell wrote:
> They can only do this if they're not using the kernel makefiles. So I
> don't really think it's a priority...
Unfortunately some of us have no choice but to use binary-only drivers.
This is starting to change, but they are currently still needed for some
hardware.
Chris
On Thu, 2004-04-15 at 15:41, Chris Friesen wrote:
> Rusty Russell wrote:
>
> > They can only do this if they're not using the kernel makefiles. So I
> > don't really think it's a priority...
>
> Unfortunately some of us have no choice but to use binary-only drivers.
>
> This is starting to change, but they are currently still needed for some
> hardware.
I think you misunderstood; even binary only module build stuff needs to
use the kernel makefiles, via make -C /path/to/kernel etc, as documented
in Documentation/kbuild/modules.txt
Arjan van de Ven wrote:
> I think you misunderstood; even binary only module build stuff needs to
> use the kernel makefiles, via make -C /path/to/kernel etc, as documented
> in Documentation/kbuild/modules.txt
I know this, you know this. There are hardware vendors that still do
not know this--or at least aren't doing it.
Chris