Hi Anouk --
--- In "Anouk Ahamitet" <> wrote:
<snip>
> The first make ran fine, with just a few warnings. But the second make
> fails with this output:
>
> scripts/kconfig/conf -s arch/arm/Kconfig
> drivers/crypto/cesa/Kconfig:16:warning: type of 'MV_CESA_TEST' redefined
> from 'tristate' to 'boolean'
> CHK include/linux/version.h
> SYMLINK include/asm-arm/arch -> include/asm-arm/arch-mv88fxx81
> make[1]: `include/asm-arm/mach-types.h' is up to date.
> CHK include/linux/utsrelease.h
> HOSTCC scripts/mod/sumversion.o
> scripts/mod/sumversion.c: In function `get_src_version':
> scripts/mod/sumversion.c:384: error: `PATH_MAX' undeclared
> (first use in this function)
> scripts/mod/sumversion.c:384: error: (Each undeclared identifier is
> reported only once
> scripts/mod/sumversion.c:384: error: for each function it appears in.)
> scripts/mod/sumversion.c:384: warning: unused variable
> `filelist'
> make[2]: *** [scripts/mod/sumversion.o] Error 1
> make[1]: *** [scripts/mod] Error 2
> make: *** [scripts] Error 2
>
>
> I found a simple patch at
> m(".../msg02788.html","//www.mail-archive.com/linux-arch");">http:
> <m(".../msg02788.html","//www.mail-archive.com/linux-arch");">http:>
> (a required header was not included) and now the kernel builds.
>
> HOWEVER...
>
> The fact that the source Technologic told me to download from their site
> did not build makes me wonder if the source contains all of the other
> adjustments they've make (which include several things for the 7800),
> since they obviously have never actually used the source that they make
> available for download. If they had, they'd know that it doesn't
> compile as-is.
No, this is wrong. Note that the failure is when compiling a script
on the *host*, using the *host* gcc. It means only that your
Ubuntu-supplied gcc/glibc/headers were tripped up by the bug, and that
the (probably older) host gcc/glibc/headers used at TS was not.
Even in reading the text of Sam's patch you linked to, it implies that
it failed only on some host systems, notably OS X, at the time
(May-07). As other distros updated gcc/glibc/headers, I'm sure the
bug hit them too in time, like Ubuntu.
> When I reporting the bug, the fix and asked my contact at Technologic
> about this, he told me that I probably needed to run make menuconfig to
> change a setting (but he didn't say which one that might be) so that the
> broken file is not included. If that is true, then it concerns me even
> more than the bug, because I wanted to start with exactly the same
> settings as Technologic so that the kernel we built as just like theirs
> except for the things we specifically wanted to change.
>
> Perhaps these things don't bother the linux gurus among Technologic's
> customers, but they concern me.
I think there is no conspiracy here ... Probably TS was trying to
offer some help, without saying "I don't know why it fails for you, it
works for me".
> Hopefully, this will at least provide a starting point to anyone else
> who needs (or wants) to rebuild the kernel for their Technologic board.
>
Yes, thanks for taking the time to post your walkthrough, I'm sure it
will help some readers. Many times info is available somewhere in the
arhives, but not often collected into one post for reference.
PS - There are much better ways of increasing the timer resolution
than by increasing HZ. I believe high resolution timers are available
for the orion5 platform, but you would need a 2.6.28 kernel I think.
regards, ......... Charlie
------------------------------------
Yahoo! Groups Links
<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/ts-7000/
<*> Your email settings:
Individual Email | Traditional
<*> To change settings online go to:
http://groups.yahoo.com/group/ts-7000/join
(Yahoo! ID required)
<*> To change settings via email:
<*> To unsubscribe from this group, send an email to:
<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/
|