Re: [uClinux-dev] Compiling problems
Hi Ron, Ron Jobmann wrote: (Posted again because I forgot subject line last time - sorry) I'm using Snapgear 3.4.0, building with the linux-2.6.x tree. Using the arm-linux-tools-20061213.tar.gz toolset, ixp420 processor, big endian. The kernel seemed to build OK. I haven't run it yet. Here's an example of an error message I'm getting now: arm-linux-ar rcu liblua.a lapi.o lcode.o ldebug.o ldo.o ldump.o lfunc.o lgc.o llex.o lmem.o lobject.o lopcodes.o lparser.o lstate.o lstring.o ltable.o ltm.o lundump.o lvm.o lzio.o lauxlib.o lbaselib.o ldblib.o liolib.o lmathlib.o loslib.o ltablib.o lstrlib.o loadlib.o linit.o arm-linux-ranlib liblua.a ucfront-gcc arm-linux-gcc -mbig-endian -O1 -pipe -fno-common -fno-builtin -Wall -Dlinux -D__linux__ -Dunix -DEMBED -c -o lua.o lua.c ucfront-gcc arm-linux-gcc -mbig-endian -o lua lua.o liblua.a -lm ucfront-gcc arm-linux-gcc -mbig-endian -O1 -pipe -fno-common -fno-builtin -Wall -Dlinux -D__linux__ -Dunix -DEMBED -c -o luac.o luac.c ucfront-gcc arm-linux-gcc -mbig-endian -O1 -pipe -fno-common -fno-builtin -Wall -Dlinux -D__linux__ -Dunix -DEMBED -c -o print.o print.c ucfront-gcc arm-linux-gcc -mbig-endian -o luac luac.o print.o liblua.a -lm make[6]: Leaving directory `/opt/0427/user/lua/src' make[5]: Leaving directory `/opt/0427/user/lua/src' make[4]: Leaving directory `/opt/0427/user/lua' [ ! -d mtd-utils ] || ( touch mtd-utils/.sgbuilt_user make -j1 -C mtd-utils ) || exit $? make[4]: Entering directory `/opt/0427/user/mtd-utils' [ -d build ] || mkdir build ucfront-gcc arm-linux-gcc -mbig-endian -O1 -pipe -fno-common -fno-builtin -Wall -Dlinux -D__linux__ -Dunix -DEMBED -D__USE_BSD -I. -g -fno-common -fno-builtin erase.c -o erase ucfront-gcc arm-linux-gcc -mbig-endian -O1 -pipe -fno-common -fno-builtin -Wall -Dlinux -D__linux__ -Dunix -DEMBED -D__USE_BSD -I. -g -fno-common -fno-builtin eraseall.c -o eraseall ucfront-gcc arm-linux-gcc -mbig-endian -O1 -pipe -fno-common -fno-builtin -Wall -Dlinux -D__linux__ -Dunix -DEMBED -D__USE_BSD -I. -g -fno-common -fno-builtin nandtest.c -o nandtest nandtest.c: In function `main': nandtest.c:120: warning: implicit declaration of function `memset' nandtest.c:266: warning: implicit declaration of function `memcpy' gcc -I/usr/include -I. -c -o build/crc32.o crc32.c gcc -I/usr/include -I. -c -o build/mkfs.jffs2.o mkfs.jffs2.c gcc -I/usr/include -I. -Dprintk=printf -DKERN_NOTICE= -DKERN_WARNING= -c -o build/compr_zlib.o compr_zlib.c compr_zlib.c:38:18: error: zlib.h: No such file or directory compr_zlib.c: In function ‘zlib_compress’: compr_zlib.c:81: error: ‘z_stream’ undeclared (first use in this function) compr_zlib.c:81: error: (Each undeclared identifier is reported only once compr_zlib.c:81: error: for each function it appears in.) compr_zlib.c:81: error: expected ‘;’ before ‘strm’ compr_zlib.c:91: error: ‘strm’ undeclared (first use in this function) compr_zlib.c:95: error: ‘Z_OK’ undeclared (first use in this function) compr_zlib.c:110: error: ‘Z_PARTIAL_FLUSH’ undeclared (first use in this function) compr_zlib.c:121: error: ‘Z_FINISH’ undeclared (first use in this function) compr_zlib.c:122: error: ‘Z_STREAM_END’ undeclared (first use in this function) compr_zlib.c: In function ‘zlib_decompress’: compr_zlib.c:143: error: ‘z_stream’ undeclared (first use in this function) compr_zlib.c:143: error: expected ‘;’ before ‘strm’ compr_zlib.c:150: error: ‘strm’ undeclared (first use in this function) compr_zlib.c:154: error: ‘Z_OK’ undeclared (first use in this function) compr_zlib.c:166: error: ‘Z_FINISH’ undeclared (first use in this function) compr_zlib.c:168: error: ‘Z_STREAM_END’ undeclared (first use in this function) make[4]: *** [build/compr_zlib.o] Error 1 make[4]: Leaving directory `/opt/0427/user/mtd-utils' make[3]: *** [mtd-utils] Error 2 make[3]: Leaving directory `/opt/0427/user' make[2]: *** [all] Error 2 make[2]: Leaving directory `/opt/0427/user' make[1]: *** [subdirs] Error 1 make[1]: Leaving directory `/opt/0427' make: *** [btr] Error 2 This all used to work. I'll try your suggestion and see what happens. I suspect it is hidden dependencies within the Makefiles that get all out of whack Have a look in the top level lib directory. Are there any broken links to lib*.a files? Remove them if there is, this should force a rebuild if required of the appropriate libs. Otehrwise have you tried to enabled explicit building of zlib in the make config lib configuration? Regards Greg when things try to build in parallel. One thing I've done so far is to hardcode HOST_NCPU=1 but that hasn't fixed much. Jivin Ron Jobmann lays it down ... / I just moved all my build tools over to a new machine, E6400 Core2 Duo / / processor. It's coming up with all sorts of compilation / /errors which I assume is because the makefiles are splitting up the / /work? The same tools and same source tree build fine on a / /single processor system. / // /Is there something special I need to setup
Re: [uClinux-dev] Compiling problems
Looks like you don't have zlib installed on your host (notice that it is doing a host build). On my Ubuntu system this is the zlib1g-dev package. Cheers, Steve On 01/05/2007, at 6:04 AM, Ron Jobmann wrote: (Posted again because I forgot subject line last time - sorry) I'm using Snapgear 3.4.0, building with the linux-2.6.x tree. Using the arm-linux-tools-20061213.tar.gz toolset, ixp420 processor, big endian. The kernel seemed to build OK. I haven't run it yet. Here's an example of an error message I'm getting now: arm-linux-ar rcu liblua.a lapi.o lcode.o ldebug.o ldo.o ldump.o lfunc.o lgc.o llex.o lmem.o lobject.o lopcodes.o lparser.o lstate.o lstring.o ltable.o ltm.o lundump.o lvm.o lzio.o lauxlib.o lbaselib.o ldblib.o liolib.o lmathlib.o loslib.o ltablib.o lstrlib.o loadlib.o linit.o arm-linux-ranlib liblua.a ucfront-gcc arm-linux-gcc -mbig-endian -O1 -pipe -fno-common -fno- builtin -Wall -Dlinux -D__linux__ -Dunix -DEMBED -c -o lua.o lua.c ucfront-gcc arm-linux-gcc -mbig-endian -o lua lua.o liblua.a -lm ucfront-gcc arm-linux-gcc -mbig-endian -O1 -pipe -fno-common -fno- builtin -Wall -Dlinux -D__linux__ -Dunix -DEMBED -c -o luac.o luac.c ucfront-gcc arm-linux-gcc -mbig-endian -O1 -pipe -fno-common -fno- builtin -Wall -Dlinux -D__linux__ -Dunix -DEMBED -c -o print.o print.c ucfront-gcc arm-linux-gcc -mbig-endian -o luac luac.o print.o liblua.a -lm make[6]: Leaving directory `/opt/0427/user/lua/src' make[5]: Leaving directory `/opt/0427/user/lua/src' make[4]: Leaving directory `/opt/0427/user/lua' [ ! -d mtd-utils ] || ( touch mtd-utils/.sgbuilt_user make -j1 -C mtd-utils ) || exit $? make[4]: Entering directory `/opt/0427/user/mtd-utils' [ -d build ] || mkdir build ucfront-gcc arm-linux-gcc -mbig-endian -O1 -pipe -fno-common -fno- builtin -Wall -Dlinux -D__linux__ -Dunix -DEMBED -D__USE_BSD -I. -g -fno-common -fno-builtin erase.c -o erase ucfront-gcc arm-linux-gcc -mbig-endian -O1 -pipe -fno-common -fno- builtin -Wall -Dlinux -D__linux__ -Dunix -DEMBED -D__USE_BSD -I. -g -fno-common -fno-builtin eraseall.c -o eraseall ucfront-gcc arm-linux-gcc -mbig-endian -O1 -pipe -fno-common -fno- builtin -Wall -Dlinux -D__linux__ -Dunix -DEMBED -D__USE_BSD -I. -g -fno-common -fno-builtin nandtest.c -o nandtest nandtest.c: In function `main': nandtest.c:120: warning: implicit declaration of function `memset' nandtest.c:266: warning: implicit declaration of function `memcpy' gcc -I/usr/include -I. -c -o build/crc32.o crc32.c gcc -I/usr/include -I. -c -o build/mkfs.jffs2.o mkfs.jffs2.c gcc -I/usr/include -I. -Dprintk=printf -DKERN_NOTICE= - DKERN_WARNING= -c -o build/compr_zlib.o compr_zlib.c compr_zlib.c:38:18: error: zlib.h: No such file or directory compr_zlib.c: In function ‘zlib_compress’: compr_zlib.c:81: error: ‘z_stream’ undeclared (first use in this function) compr_zlib.c:81: error: (Each undeclared identifier is reported only once compr_zlib.c:81: error: for each function it appears in.) compr_zlib.c:81: error: expected ‘;’ before ‘strm’ compr_zlib.c:91: error: ‘strm’ undeclared (first use in this function) compr_zlib.c:95: error: ‘Z_OK’ undeclared (first use in this function) compr_zlib.c:110: error: ‘Z_PARTIAL_FLUSH’ undeclared (first use in this function) compr_zlib.c:121: error: ‘Z_FINISH’ undeclared (first use in this function) compr_zlib.c:122: error: ‘Z_STREAM_END’ undeclared (first use in this function) compr_zlib.c: In function ‘zlib_decompress’: compr_zlib.c:143: error: ‘z_stream’ undeclared (first use in this function) compr_zlib.c:143: error: expected ‘;’ before ‘strm’ compr_zlib.c:150: error: ‘strm’ undeclared (first use in this function) compr_zlib.c:154: error: ‘Z_OK’ undeclared (first use in this function) compr_zlib.c:166: error: ‘Z_FINISH’ undeclared (first use in this function) compr_zlib.c:168: error: ‘Z_STREAM_END’ undeclared (first use in this function) make[4]: *** [build/compr_zlib.o] Error 1 make[4]: Leaving directory `/opt/0427/user/mtd-utils' make[3]: *** [mtd-utils] Error 2 make[3]: Leaving directory `/opt/0427/user' make[2]: *** [all] Error 2 make[2]: Leaving directory `/opt/0427/user' make[1]: *** [subdirs] Error 1 make[1]: Leaving directory `/opt/0427' make: *** [btr] Error 2 This all used to work. I'll try your suggestion and see what happens. I suspect it is hidden dependencies within the Makefiles that get all out of whack when things try to build in parallel. One thing I've done so far is to hardcode HOST_NCPU=1 but that hasn't fixed much. Jivin Ron Jobmann lays it down ... I just moved all my build tools over to a new machine, E6400 Core2 Duo processor. It's coming up with all sorts of compilation errors which I assume is because the makefiles are splitting up the work? The same tools and same source tree build fine on a single processor system. Is there something special I need to setup in my build environment on my new PC? Which dist are you using ? What mods have you made ? In a
Re: [uClinux-dev] Compiling problems with busybox(MicroBlaze)!
Hello,
Try the attached patch. Or better still, use PetaLinux when deveoping
for MicroBlaze.
http://developer.petalogix.com
Regaqrds,
John
xuyun wrote:
Hi,everyone.I've already done everything I was told according to the
document:uClinux_ready_MicroBlaze_design.pdf. Until I came to make all
after finishing make dep. It appears that something went wrong at the
stage of compiling busybox:
/home/Simux/package/uClinux-dist/micro-elf-tools/bin/../lib/gcc/microblaze/3.4.1/../../../../microblaze/bin/ld.real:
unrecognized option `--fatal-warnings'
/home/Simux/package/uClinux-dist/micro-elf-tools/bin/../lib/gcc/microblaze/3.4.1/../../../../microblaze/bin/ld.real:
use the --help option for usage information
collect2: ld returned 1 exit status
make[4]: *** [busybox] Error 1
make[4]: Leaving directory `/home/Simux/package/uClinux-dist/user/busybox'
make[3]: *** [all] Error 2
make[3]: Leaving directory `/home/Simux/package/uClinux-dist/user/busybox'
Does anyone know how to settle this problem?
___
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
---BeginMessage---
Hi,
ucfront-ld tool chokes on the NONE libc option (for standalone
toolchains with built-in uClibc, for example).
Dumping the environment inside config/common/config.arch, I have:
CONFIG_DEFAULTS_LIBC_NONE=y
CONFIG_LIBCDIR=
Here's what ucfront-ld says about that:
FATAL: Could not determine libc. Are $CONFIG_DEFAULTS_LIBC_... and
$CONFIG_LIBCDIR set correctly?
Obviously in the LIBC_NONE case ucfront-ld doesn't have a lot to do, but
one place it is used is when common/config.arch tests linker support for
--fatal-warnings:
ifeq $(shell $(LD) --fatal-warnings 21 | grep 'unrecogni.ed
option')
# Linker warnings are almost always a sign of badness
LDFLAGS += -Wl,--fatal-warnings
endif
With LIBC_NONE, ucfront-ld doesn't get as far as invoking $(CROSS)-ld -
it just pukes about LIBCDIR.
ucfront-ld assumes that if it's CONFIG_DEFAULTS_LIBC_NONE, then
CONFIG_LIBCDIR should not be set. This is wrong, CONFIG_LIBCDIR is set,
but empty. There's another error whereby it would pass an empty
libdirectory on the command line, so we'd get
$(LD) ... -L {nothing} ...
which is also bogus.
Attached patch seems to work OK here, but I couldn't actually find any
dist apps that explicitly invoke the linker - all seem to do it via
$(GCC). Any comments?
Thanks,
John
Index: tools/ucfront/ucfront-ld.c
===
--- tools/ucfront/ucfront-ld.c (revision 2231)
+++ tools/ucfront/ucfront-ld.c (working copy)
@@ -282,6 +282,9 @@
x_asprintf(libc_libdir, %s/lib/%s, rootdir,
config_libcdir);
}
}
+ else if (getenv(CONFIG_DEFAULTS_LIBC_NONE)) {
+ libtype = LIBTYPE_NONE;
+ }
else {
fatal(Could not determine libc. Are $CONFIG_DEFAULTS_LIBC_...
and $CONFIG_LIBCDIR set correctly?);
}
@@ -325,8 +328,10 @@
if (!nostdlib) {
args_add(stripped_args, -nostdlib);
- args_add(stripped_args, -L);
- args_add(stripped_args, libc_libdir);
+ if(libc_libdir) {
+ args_add(stripped_args, -L);
+ args_add(stripped_args, libc_libdir);
+ }
x_asprintf(e, %s/lib, rootdir);
args_add(stripped_args, -L);
___
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---End Message---
___
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
Re: [uClinux-dev] Compiling problems with STLport 5.0 in uClinuxdist200060803
On Mon, 2007-02-26 at 01:25 +0100, Francesco Rendine wrote: - Original Message - From: Gavin Lambert [EMAIL PROTECTED] To: 'uClinux development list' uclinux-dev@uclinux.org Sent: Sunday, February 25, 2007 22:10 Subject: RE: [uClinux-dev] Compiling problems with STLport 5.0 in uClinuxdist200060803 Looks like your shell is not expanding the filenames properly. Are you running under cygwin or something? If so, make sure you do the make from within bash. Absolutely no.My environment is Ubuntu 6.10. I don't know because I get that error. Is there someone that can explain to me this error? I think Ubuntu uses dash as their default shell (/bin/sh). This maybe the reason for the expansion problem. Try replacing it with bash? Regards, Stuart ___ 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
Re: [uClinux-dev] Compiling problems with STLport 5.0 in uClinuxdist200060803
- Original Message - From: Gavin Lambert [EMAIL PROTECTED] To: 'uClinux development list' uclinux-dev@uclinux.org Sent: Sunday, February 25, 2007 22:10 Subject: RE: [uClinux-dev] Compiling problems with STLport 5.0 in uClinuxdist200060803 Looks like your shell is not expanding the filenames properly. Are you running under cygwin or something? If so, make sure you do the make from within bash. Absolutely no.My environment is Ubuntu 6.10. I don't know because I get that error. Is there someone that can explain to me this error? __ 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 ___ 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
