Hi Dave,

Dave Rensberger wrote:
The problems that I was having yesterday with bcopy and bzero were largely due 
to my never having run 'make oldconfig' to import the uClibc settings that I 
had previously been using (with a Snapgear 3.5 release).    However, after 
trying to properly configure my uClibc, really strange things start to happen.  
At the beginning of the uClibc build, I get the following message:

  <stdin>:1:24: error: asm/unistd.h: No such file or directory
  <stdin>:1:24: error: asm/unistd.h: No such file or directory
I looked in the 2.6 kernel directory and discovered that there is was no link from 'include/asm/'. I also discovered that there were only 3 'asm-*' directories at all (asm-arm, asm-generic, and asm-nios2nommu).

That because in modern kernel versions the architecture specific asm
include directories have moved int the top level kernel "arch"
directories (so include/asm-m68knommu is now arch/m68knommu/include/asm
for example).


  I chose to make a link from 'asm' to 'asm-generic', because it was the only 
one that seemed to make sense to me, but I have a little bit of an 
uncomfortable feeling about having had to manually create the link, and also 
about the fact that there are only 3 'asm-*' choices (whereas previous kernels 
would have a ton of those directories for every architecture imaginable).   Do 
these observations indicate something unusual, or is this just something that 
has been cleaned up in recent versions of the kernel?

You don't want to link to asm-generic. You would want to link to
the appropriate arch include/asm directory.

But... All this is done automatically in the normal build flow
of the uClinux-dist. You shouldn't need to be doing any of
this manually.


After I manually added the 'asm' link, the uClibc build stopped reporting that error, but still 
went on to report that all of the syscall symbols ("__NR_*") were undeclared (even though 
they're clearly declared n the "unistd.h" file.

Is it possible that the fairly old uClibc in 20100315 just isn't compatible 
with the extremely new 2.6.33 kernel for some architectures?

No. The code in that dist works "as is". I have an automated build
of that source that runs very night and cleanly builds on approximately
150 board/kernel combinations. And it works on the dozens of targets
that I myself can try it on.


  Could this also be due to the snapgear i386-linux cross-compiler that I'm using 
(it's the latest one on the snapgear site, but it's a 3 or 4 year old 4.2.1 
derived gcc)?  Is the 2009 release of uClinux known to be any better with that 
cross-compiler.  I'd kind of like to get the really new release working, but at 
the end of the day, all I'm trying to get by upgrading is libxml and a >2.6.20 
kernel, so I could use the release from last year.

Take a step back for a minute. Try building somehting that is
known to work, on unmodified uClinux-dist code.

Try building the Soekris/net4801 target with the 2.6.x kernel and
uClibc for example. That is an x86 target I build test, you should
be able to configure for that target and build, and get a clean
compile.

Regards
Greg


------------------------------------------------------------------------
Greg Ungerer  --  Principal Engineer        EMAIL:     g...@snapgear.com
SnapGear Group, McAfee                      PHONE:       +61 7 3435 2888
8 Gardner Close                             FAX:         +61 7 3217 5323
Milton, QLD, 4064, Australia                WEB: http://www.SnapGear.com
_______________________________________________
uClinux-dev mailing list
uClinux-dev@uclinux.org
http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
This message was resent by uclinux-dev@uclinux.org
To unsubscribe see:
http://mailman.uclinux.org/mailman/options/uclinux-dev

Reply via email to