On 2008-09-17, Grant Edwards <[EMAIL PROTECTED]> wrote:
> On 2008-09-16, Grant Edwards <[EMAIL PROTECTED]> wrote:
>> I'm attempting to follow the "getting started" article at
>> http://www.ucdot.org/archive/tb/tb20020807.shtml. I'm trying
>> to build uClinux-dist-20080808 for the xcopilot target using
>> toolchain binaries from m68k-uclinux-tools-20061214.tar.bz2.
>>
>> None of the kernel versions will build.
>
> I gave up on the xcopilot target, and decided to try to build
> the Samsung S3C4510B target using arm-linux-tools-20070808.
>
> There is no 2.6 or 2.0 configuration for the S3C4510, so I
> tried to build 2.4. That fails:
OK, so I gave up on xcopilot, and I gave up on S3C4510.
There must be at least _one_ target that builds -- right?
Seriously. There is, isn't there?
Next, I decided to try to build for the Snapgear LITE target.
Since I've got a couple Snapgear LITES sitting in a box
somewhere, I thought I'd try it next.
Here's how that fails:
$ make dep
which: no m68k-uclinux-20060615-gcc in
(/opt/uclinux/bin:/home/grante/bin:/usr/local/bin:/usr/bin:/bin:/opt/bin:/usr/i486-pc-linux-gnu/gcc-bin/4.1.2:/usr/kde/3.5/bin:/usr/qt/3/bin:/opt/gnu/bin)
make ARCH=m68knommu CROSS_COMPILE=m68k-uclinux- -C linux-2.4.x dep
make[1]: Entering directory `/home/grante/uclinux/uClinux-dist/linux-2.4.x'
rm -f .depend .hdepend
make _sfdep_arch/m68knommu/kernel _sfdep_arch/m68knommu/mm
_sfdep_arch/m68knommu/lib _sfdep_arch/m68knommu/platform/5272 _sfdep_kernel
_sfdep_drivers _sfdep_mmnommu _sfdep_fs _sfdep_net _sfdep_ipc _sfdep_lib
_sfdep_crypto _FASTDEP_ALL_SUB_DIRS="arch/m68knommu/kernel arch/m68knommu/mm
arch/m68knommu/lib arch/m68knommu/platform/5272 kernel drivers mmnommu fs net
ipc lib crypto"
make[2]: Entering directory `/home/grante/uclinux/uClinux-dist/linux-2.4.x'
make -C arch/m68knommu/kernel fastdep
make[3]: Entering directory
`/home/grante/uclinux/uClinux-dist/linux-2.4.x/arch/m68knommu/kernel'
/home/grante/uclinux/uClinux-dist/linux-2.4.x/scripts/mkdep -fno-builtin
-nostdinc -D__KERNEL__ -I/home/grante/uclinux/uClinux-dist/linux-2.4.x/include
-Wall -Wstrict-prototypes -Wno-trigraphs -O2 -fno-strict-aliasing -fno-common
-fno-builtin-sprintf -fomit-frame-pointer -Wno-pointer-sign -I
/usr/local/lib/gcc/m68k-uclinux/4.1.1//include -pipe -DNO_MM -DNO_FPU -m5307
-Wa,-S -Wa,-m5307 -D__ELF__ -DMAGIC_ROM_PTR -DUTS_SYSNAME=\"uClinux\"
-D__linux__ -O1 -nostdinc -iwithprefix include -- bios32.c console.c
m68k_defs.c m68k_ksyms.c process.c ptrace.c semaphore.c setup.c sys_m68k.c
time.c traps.c > .depend
realpath(/usr/local/lib/gcc/m68k-uclinux/4.1.1//include) failed, No such
file or directory
make[3]: *** [fastdep] Error 1
make[3]: Leaving directory
`/home/grante/uclinux/uClinux-dist/linux-2.4.x/arch/m68knommu/kernel'
make[2]: *** [_sfdep_arch/m68knommu/kernel] Error 2
make[2]: Leaving directory `/home/grante/uclinux/uClinux-dist/linux-2.4.x'
make[1]: *** [dep-files] Error 2
make[1]: Leaving directory `/home/grante/uclinux/uClinux-dist/linux-2.4.x'
make: *** [dep] Error 2
I'm a little suspicious of that first line of output from
which. Why is looking for m68k-uclinux-20060615-gcc?
$ grep -r 20060615 .
./vendors/config/m68knommu/config.arch:ifneq ($(shell which
m68k-uclinux-20060615-gcc),)
./vendors/config/m68knommu/config.arch:CROSS_COMPILE = m68k-uclinux-20060615-
What's so special about that particular version of the
m68k-uclinux toolchain?
Should we not use a later toolchain?
Is using too recent a toolchain with m68k targets what causes
the thousands of warnings like these?
namei.c:2050: warning: matching constraint does not allow a register
namei.c:2050: warning: matching constraint does not allow a register
namei.c:2050: warning: matching constraint does not allow a register
namei.c:2050: warning: matching constraint does not allow a register
namei.c:2050: warning: matching constraint does not allow a register
namei.c:2050: warning: matching constraint does not allow a register
Are those warnings something about which I should be concerned?
I'm not sure if that complaint from "which" has anything to do
with the later failure which is caused by a non-existant
directory path being passed to mkdep:
-I /usr/local/lib/gcc/m68k-uclinux/4.1.1//include
That's wront because my toolchain is not installed in
/usr/local. I do development for several different targets and
OSes, and you can't assuming you can install things with names
like m68k-elf-gcc in /usr/local/bin without conflicts. So the
uclinux tools are installed in /opt/uclinux instead of
/usr/local.
But, I can't figure out where that bogus path is being set. The
most portable thing to do would be to do something like the
following (in bash syntax):
$(dirname $(${CROSS_COMPILE}-gcc --print-libgcc-file))/include
Anyhow, I'll add a symlink from /usr/local/lib/gcc/m68k-uclinux
and try again...
--
Grant
_______________________________________________
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
