Re: Problems compiling 2.6.26 kernel package on NSLU2 (Slug)
On Wed, Oct 29, 2008 at 08:47:00PM -0400, JLB wrote:
>
>
> On Thu, 30 Oct 2008, Matthew Palmer wrote:
>
>> On Wed, Oct 29, 2008 at 08:25:41PM -0400, JLB wrote:
>>> On Thu, 30 Oct 2008, Matthew Palmer wrote:
>>>> On Wed, Oct 29, 2008 at 06:42:28PM -0400, JLB wrote:
>>>>> Then, following http://www.nslu2-linux.org/wiki/Debian/BuildImage as a
>>>>> guide, and after dpkg-source -x'ing the .dsc, I did the following:
>>>>>
>>>>> # fakeroot make -f debian/rules.gen setup_arm_none_ixp4xx >>
>>>>> ../kernel-build.log 2>&1
>>>>> # cd debian/build/build-arm_none_ixp4xx
>>>>> # make ARCH=arm menuconfig
>>>>> # (here, I configured kernel options)
>>>>> # fakeroot make -f debian/rules.gen binary-arch_arm_none_ixp4xx >>
>>>>> ../kernel-build.log 2>&1
>>>>>
>>>>> The kernel merrily built its way along for around 24-36 hours, then
>>>>> puked. The tail -30 of kernel-build.log is as follows:
>>>>
>>>> There's nothing particularly useful in that snippet of log; you might want
>>>> to put the whole log up somewhere for people to view and then throw the URL
>>>> in here.
>>>
>>> The whole log may not be much more illuminating, but I've put it online
>>> at:
>>>
>>> http://tinyurl.com/5sz3bs
>>>
>>> The whole shebang is around 900KB.
>>
>> Turns out the log is very illuminating. Just before the big symbol list,
>> there's a line:
>>
>> ABI has changed! Refusing to continue.
>>
>>>> Since it's waffling on about symbols, I'm wondering if you've managed to
>>>> change the kernel ABI so it needs bumping. Take a look at the "ABI changes"
>>>> section of http://wiki.debian.org/DebianKernelCustomCompilation to see if it
>>>> applies to you.
>>>
>>> I have no idea what this section is talking about, so I guess that's a
>>> 'no'...
>>
>> Au contraire, that section mentions the error "ABI has changed!" which is
>> exactly what you've got. So it does apply to you, and you need to follow
>> the instructions in that section of the wiki page.
>>
>>> As noted, I obtained an original Linux kernel source tarball from the
>>> Debian repository, along with the .dsc, etc. Aside from the changes made
>>> by the dsc/diff itself, I did not make any changes at all to the kernel
>>> source tree. :(
>>
>> A patch isn't the only way to change the ABI. Many kernel options can have
>> an effect on the publically available data structures. Given the number of
>> symbols that were added/changed/removed, you did a *lot* of changes to the
>> kernel config. So, you can either handle the ABI change, or else revert to
>> the original config and only adjust the bare minimum that's required to make
>> your device work, and hope that those changes don't touch any data
>> structures.
>
> Gyaaaaah. So you're saying that *the modules I chose to build* broke the
> compile?
Building a self-contained module won't change the kernel's ABI, but not
everything you changed was necessarily an independent module. In fact,
looking through the list of changed symbols, it looks like you did a *lot*
of changes. Did you use the .config from your existing kernel as a starting
point, or did you just dive in?
> If ticking a box to compile a module will cause the kernel compile to
> puke, why is the option even made available? (Shouldn't there be some
> kind of warning, like 'choosing to compile this module may break your
> kernel compile'? ;) )
The build isn't broken, it just needs more things changed than just fiddling
with menuconfig. (If you want to *really* break your kernel build, enable
the ATH5K driver... gah!)
It's only the Debian kernel build that's having problems, though -- you can
build a kernel itself however you like. The Debian kernel build process is
just making sure that when it declares a particular ABI (for out-of-tree
module packages to build against) that it does't break unnecessarily.
> More seriously, is there any way of telling which symbols changed the
> ABI? Are there any likely contenders in that list? This is all greek to
> me; the only thing that comes to mind when I hear 'binary interface' is
> 'ELF, or in the olden days a.out', and I certainly didn't disable ELF or
> tell it to compile in a.out......
No, "binary interface" in this case means the exact layout in memory of
various structures, the arguments (and their types) that all functions
available to a kernel module take, and that sort of thing. A really simple
(hypothetical) example of this might be:
struct process_perf_counter {
int cpu_time,
int io_ops,
#ifdef CONFIG_EXTENDED_DEBUG_INFO
int page_faults,
#endif
};
If you choose the "Store extended debug info (EXPERIMENTAL)" option in your
kernel config, you'll get an entry in Changed symbols for the
process_perf_counter struct.
Basically, if you want to minimise the changes of breaking the ABI, then
minimise the config changes you make to the kernel. As I said before, start
from the config for your existing running kernel and then tweak only what
you really need to to make it all work.
- Matt
Reply to: