Building the ARM footbridge_defconfig provokes this build error:
CC drivers/net/ne2k-pci.o
drivers/net/ne2k-pci.c:123: error: pci_clone_list causes a section type conflict
make[2]: *** [drivers/net/ne2k-pci.o] Error 1
make[1]: *** [drivers/net] Error 2
make: *** [drivers] Error 2
make: Leaving directory `/var/tmp/kernel-orig'
static const struct {
char *name;
int flags;
} pci_clone_list[] __devinitdata = {
const data can't be __devinitdata.
--
Russell King
Linux kernel 2.6 ARM Linux - http://www.arm.linux.org.uk/
maintainer of: 2.6 Serial core
On Thu, 2006-03-23 at 16:41 +0000, Russell King wrote:
> Building the ARM footbridge_defconfig provokes this build error:
>
> CC drivers/net/ne2k-pci.o
> drivers/net/ne2k-pci.c:123: error: pci_clone_list causes a section type conflict
> make[2]: *** [drivers/net/ne2k-pci.o] Error 1
> make[1]: *** [drivers/net] Error 2
> make: *** [drivers] Error 2
> make: Leaving directory `/var/tmp/kernel-orig'
>
> static const struct {
> char *name;
> int flags;
> } pci_clone_list[] __devinitdata = {
>
> const data can't be __devinitdata.
that's a gcc bug; probably arm specific even?
On Thu, Mar 23, 2006 at 05:52:12PM +0100, Arjan van de Ven wrote:
> On Thu, 2006-03-23 at 16:41 +0000, Russell King wrote:
> > Building the ARM footbridge_defconfig provokes this build error:
> >
> > CC drivers/net/ne2k-pci.o
> > drivers/net/ne2k-pci.c:123: error: pci_clone_list causes a section type conflict
> > make[2]: *** [drivers/net/ne2k-pci.o] Error 1
> > make[1]: *** [drivers/net] Error 2
> > make: *** [drivers] Error 2
> > make: Leaving directory `/var/tmp/kernel-orig'
> >
> > static const struct {
> > char *name;
> > int flags;
> > } pci_clone_list[] __devinitdata = {
> >
> > const data can't be __devinitdata.
>
>
> that's a gcc bug; probably arm specific even?
It's gcc 4.01... the kautobuild folk are going to try gcc 4.04 instead.
--
Russell King
Linux kernel 2.6 ARM Linux - http://www.arm.linux.org.uk/
maintainer of: 2.6 Serial core
On Thu, Mar 23, 2006 at 04:55:58PM +0000, Russell King wrote:
> On Thu, Mar 23, 2006 at 05:52:12PM +0100, Arjan van de Ven wrote:
> > On Thu, 2006-03-23 at 16:41 +0000, Russell King wrote:
> > > Building the ARM footbridge_defconfig provokes this build error:
> > >
> > > CC drivers/net/ne2k-pci.o
> > > drivers/net/ne2k-pci.c:123: error: pci_clone_list causes a section type conflict
> > > make[2]: *** [drivers/net/ne2k-pci.o] Error 1
> > > make[1]: *** [drivers/net] Error 2
> > > make: *** [drivers] Error 2
> > > make: Leaving directory `/var/tmp/kernel-orig'
> > >
> > > static const struct {
> > > char *name;
> > > int flags;
> > > } pci_clone_list[] __devinitdata = {
> > >
> > > const data can't be __devinitdata.
> >
> >
> > that's a gcc bug; probably arm specific even?
>
> It's gcc 4.01... the kautobuild folk are going to try gcc 4.04 instead.
Actually, given that it also appears with gcc 3.3, I'd like to request
that the change (along with all the other const __devinitdata's) are
backed out.
The comments I'm hearing about gcc 4.1 on ARM indicate that it's a case
of "there be big beasts there, don't touch with a barge pole". To quote
some comments about gcc 4.1 on ARM:
"yeah, 4.1 is quite bad on arm. it's supposed to have all the EABI bits,
but it can't even build itself without ICEing and segfaulting left right
and center"
"the debian arm failures with gcc 4.1 are just scary. the current gcc
4.1s miscompile even very basic for/while loops"
which probably leaves ARM folk with a very narrow set of working gcc
versions.
So, I've no idea at present which gcc version we should be considering
nominating as "the sole gcc version the kernel supports".
--
Russell King
Linux kernel 2.6 ARM Linux - http://www.arm.linux.org.uk/
maintainer of: 2.6 Serial core
On Thu, 2006-03-23 at 17:40 +0000, Russell King wrote:
> On Thu, Mar 23, 2006 at 04:55:58PM +0000, Russell King wrote:
> > On Thu, Mar 23, 2006 at 05:52:12PM +0100, Arjan van de Ven wrote:
> > > On Thu, 2006-03-23 at 16:41 +0000, Russell King wrote:
> > > > Building the ARM footbridge_defconfig provokes this build error:
> > > >
> > > > CC drivers/net/ne2k-pci.o
> > > > drivers/net/ne2k-pci.c:123: error: pci_clone_list causes a section type conflict
> > > > make[2]: *** [drivers/net/ne2k-pci.o] Error 1
> > > > make[1]: *** [drivers/net] Error 2
> > > > make: *** [drivers] Error 2
> > > > make: Leaving directory `/var/tmp/kernel-orig'
> > > >
> > > > static const struct {
> > > > char *name;
> > > > int flags;
> > > > } pci_clone_list[] __devinitdata = {
> > > >
> > > > const data can't be __devinitdata.
> > >
> > >
> > > that's a gcc bug; probably arm specific even?
> >
> > It's gcc 4.01... the kautobuild folk are going to try gcc 4.04 instead.
>
> Actually, given that it also appears with gcc 3.3, I'd like to request
> that the change (along with all the other const __devinitdata's) are
> backed out.
ok that's entirely reasonable and I'm perfectly ok with that.
On Thu, 23 Mar 2006 17:40:14 +0000, Russell King wrote:
>> It's gcc 4.01... the kautobuild folk are going to try gcc 4.04 instead.
>
>Actually, given that it also appears with gcc 3.3, I'd like to request
>that the change (along with all the other const __devinitdata's) are
>backed out.
>
>The comments I'm hearing about gcc 4.1 on ARM indicate that it's a case
>of "there be big beasts there, don't touch with a barge pole". To quote
>some comments about gcc 4.1 on ARM:
>
>"yeah, 4.1 is quite bad on arm. it's supposed to have all the EABI bits,
> but it can't even build itself without ICEing and segfaulting left right
> and center"
>
>"the debian arm failures with gcc 4.1 are just scary. the current gcc
> 4.1s miscompile even very basic for/while loops"
>
>which probably leaves ARM folk with a very narrow set of working gcc
>versions.
>
>So, I've no idea at present which gcc version we should be considering
>nominating as "the sole gcc version the kernel supports".
Just a data point...
My ARM GCCs are configured for the default arm-linux ABI,
not the EABI, and gcc-4.0.3 and gcc-4.1 both appear to be
solid for user-space code; they also bootstrap themselves
(on an ARM) just fine. I haven't used them for kernels however.
On the other hand, gcc-3.3.6 and gcc-3.4.6 both require several
add-on patches to fix incorrect code generation, and even then
there are a couple of known unfixed bugs (PR25133 and PR26463 in
particular; PR25133 can be worked around but PR26463 scares me).
/Mikael