All, I've never had success with Fiasco but decided to give it another go so I could run some benchmarks. In short, I had one success and two failures. Any help would be appreciated.
1) I can build Fiasco for x86 on the host (32 bit x86 system). Yay 2) Can't build Fiasco for ARM on an x86 host due to... an old arm-linux-gcc version? 3) Can't build L4Re due to linker error.
1) Successful build of Fiasco x86 This and other builds are using a recent pull from the repo [1] on a Fedora based 32bit x86 system running gcc 4.4.4 on Linux 2.6.34.
2) Failure to build Fiasco ARM This early failure seems to be a simple problem with gcc changing the arguments - can anyone tell me the version of the "official" arm compiler in use? I'm running arm-linux-gcc 3.4.4.
------------ make[1]: Entering directory `/home/tommd/dev/L4/L4Re/build_arm' ... Generating version information ... Making kip.o cc1plus: error: invalid option `abi=apcs-gnu' make[1]: *** [kip.o] Error 1 -------------
3) Failure to build L4Re due to linker error
The symbol "__stack_chk_fail_local" is missing when building "libl4util.so" (see below). A quick objdump/grep doesn't show this symbol in any object file in the build directory - is the build system slightly broken? I see the source definition but don't really want to hack around in the build system.
$ ld --version GNU ld version 2.20.51.0.2-20.fc13 20091009
------------- make[5]: Entering directory `/home/tommd/dev/L4/L4Re/build/pkg/l4util/lib/src/OBJ-x86_core2-l4f' ==> Linking to shared libl4util.so /usr/lib/gcc/i686-redhat-linux/4.4.4/libgcc_eh.a(unwind-dw2.o): In function `.L107': (.text+0xb79): undefined reference to `__stack_chk_fail_local' /usr/lib/gcc/i686-redhat-linux/4.4.4/libgcc_eh.a(unwind-dw2.o): In function `.L358': (.text+0x1a85): undefined reference to `__stack_chk_fail_local' /usr/lib/gcc/i686-redhat-linux/4.4.4/libgcc_eh.a(unwind-dw2.o): In function `_Unwind_Backtrace': (.text+0x24bf): undefined reference to `__stack_chk_fail_local' /usr/lib/gcc/i686-redhat-linux/4.4.4/libgcc_eh.a(unwind-dw2.o): In function `_Unwind_ForcedUnwind': (.text+0x26ad): undefined reference to `__stack_chk_fail_local' /usr/lib/gcc/i686-redhat-linux/4.4.4/libgcc_eh.a(unwind-dw2.o): In function `__frame_state_for': (.text+0x29e8): undefined reference to `__stack_chk_fail_local' /usr/lib/gcc/i686-redhat-linux/4.4.4/libgcc_eh.a(unwind-dw2.o):(.text+0x2b78): more undefined references to `__stack_chk_fail_local' follow ld: libl4util.so: hidden symbol `__stack_chk_fail_local' isn't defined ld: final link failed: Nonrepresentable section on output make[5]: *** [libl4util.so] Error 1 ----------------
Cheers, Thomas
Hi,
On Fri Oct 29, 2010 at 12:09:52 -0700, Thomas DuBuisson wrote:
I've never had success with Fiasco but decided to give it another go so I could run some benchmarks. In short, I had one success and two failures. Any help would be appreciated.
- I can build Fiasco for x86 on the host (32 bit x86 system). Yay
- Can't build Fiasco for ARM on an x86 host due to... an old
arm-linux-gcc version? 3) Can't build L4Re due to linker error.
- Successful build of Fiasco x86
This and other builds are using a recent pull from the repo [1] on a Fedora based 32bit x86 system running gcc 4.4.4 on Linux 2.6.34.
Ok.
- Failure to build Fiasco ARM
This early failure seems to be a simple problem with gcc changing the arguments - can anyone tell me the version of the "official" arm compiler in use? I'm running arm-linux-gcc 3.4.4.
make[1]: Entering directory `/home/tommd/dev/L4/L4Re/build_arm' ... Generating version information ... Making kip.o cc1plus: error: invalid option `abi=apcs-gnu' make[1]: *** [kip.o] Error 1
I'm mainly using the codesourcery ones nowadays (4.4). Nevertheless, does it help if you remove the abi=apcs-gnu line in src/Makeconf.arm?
- Failure to build L4Re due to linker error
The symbol "__stack_chk_fail_local" is missing when building "libl4util.so" (see below). A quick objdump/grep doesn't show this symbol in any object file in the build directory - is the build system slightly broken? I see the source definition but don't really want to hack around in the build system.
$ ld --version GNU ld version 2.20.51.0.2-20.fc13 20091009
make[5]: Entering directory `/home/tommd/dev/L4/L4Re/build/pkg/l4util/lib/src/OBJ-x86_core2-l4f' ==> Linking to shared libl4util.so /usr/lib/gcc/i686-redhat-linux/4.4.4/libgcc_eh.a(unwind-dw2.o): In function `.L107': (.text+0xb79): undefined reference to `__stack_chk_fail_local' /usr/lib/gcc/i686-redhat-linux/4.4.4/libgcc_eh.a(unwind-dw2.o): In function `.L358':
Could you do a 'make clean' and 'make V=1' and check whether a '-fno-stack-protector' is there somewhere on the gcc command line?
Thanks, Adam
- Failure to build Fiasco ARM
This early failure seems to be a simple problem with gcc changing the arguments - can anyone tell me the version of the "official" arm compiler in use? I'm running arm-linux-gcc 3.4.4.
make[1]: Entering directory `/home/tommd/dev/L4/L4Re/build_arm' ... Generating version information ... Making kip.o cc1plus: error: invalid option `abi=apcs-gnu' make[1]: *** [kip.o] Error 1
I'm mainly using the codesourcery ones nowadays (4.4). Nevertheless, does it help if you remove the abi=apcs-gnu line in src/Makeconf.arm?
That causes it to fail just as early with a different message. I'll try with 4.4 and get back to the list on results, thanks.
- Failure to build L4Re due to linker error
The symbol "__stack_chk_fail_local" is missing when building "libl4util.so" (see below). A quick objdump/grep doesn't show this symbol in any object file in the build directory - is the build system slightly broken? I see the source definition but don't really want to hack around in the build system.
$ ld --version GNU ld version 2.20.51.0.2-20.fc13 20091009
make[5]: Entering directory `/home/tommd/dev/L4/L4Re/build/pkg/l4util/lib/src/OBJ-x86_core2-l4f' ==> Linking to shared libl4util.so /usr/lib/gcc/i686-redhat-linux/4.4.4/libgcc_eh.a(unwind-dw2.o): In function `.L107': (.text+0xb79): undefined reference to `__stack_chk_fail_local' /usr/lib/gcc/i686-redhat-linux/4.4.4/libgcc_eh.a(unwind-dw2.o): In function `.L358':
Could you do a 'make clean' and 'make V=1' and check whether a '-fno-stack-protector' is there somewhere on the gcc command line?
Yes, I see -fno-stack-protector on the gcc calls, for example: ---------------------------- LD_PRELOAD=libgendep.so LD_LIBRARY_PATH=:/home/tommd/dev/L4/L4Re/build/tool/gendep/32 GENDEP_TARGET=list_alloc.s.o GENDEP_BINARY=cc1 gcc -m32 -c -DL4SYS_USE_UTCB_WRAP=1 -DSYSTEM_x86_core2_l4f -DARCH_x86 -DCPUTYPE_core2 -DL4API_l4f -D_GNU_SOURCE -I/home/tommd/dev/L4/L4Re/build/pkg/l4util/idl/OBJ-x86-l4f -I/home/tommd/dev/L4/L4Re/build/include/x86/l4f -I/home/tommd/dev/L4/L4Re/build/include/l4f -I/home/tommd/dev/L4/L4Re/build/include/x86 -I/home/tommd/dev/L4/L4Re/build/include -nostdinc -I/home/tommd/dev/L4/L4Re/build/include/x86/uclibc -I/home/tommd/dev/L4/L4Re/build/include/uclibc -I/home/tommd/dev/L4/L4Re/build/include/contrib/libstdc++-v3 -I/usr/lib/gcc/i686-redhat-linux/4.4.4/include -I/usr/lib/gcc/i686-redhat-linux/4.4.4/include-fixed -g -O2 -fno-strict-aliasing -march=core2 -Wextra -Wall -Wstrict-prototypes -Wmissing-prototypes -Wmissing-declarations -fno-common -std=gnu99 -fno-stack-protector -fPIC -U__PIC__ -D__PIC__=1 /home/tommd/dev/L4/L4Re/src/l4/pkg/l4util/lib/src/list_alloc.c -o list_alloc.s.o -----------------------------
Cheers, Thomas
On Sun Oct 31, 2010 at 14:48:51 -0700, Thomas DuBuisson wrote:
I'm mainly using the codesourcery ones nowadays (4.4). Nevertheless, does it help if you remove the abi=apcs-gnu line in src/Makeconf.arm?
That causes it to fail just as early with a different message. I'll try with 4.4 and get back to the list on results, thanks.
Ok, thanks.
- Failure to build L4Re due to linker error
The symbol "__stack_chk_fail_local" is missing when building "libl4util.so" (see below). A quick objdump/grep doesn't show this symbol in any object file in the build directory - is the build system slightly broken? I see the source definition but don't really want to hack around in the build system.
$ ld --version GNU ld version 2.20.51.0.2-20.fc13 20091009
make[5]: Entering directory `/home/tommd/dev/L4/L4Re/build/pkg/l4util/lib/src/OBJ-x86_core2-l4f' ==> Linking to shared libl4util.so /usr/lib/gcc/i686-redhat-linux/4.4.4/libgcc_eh.a(unwind-dw2.o): In function `.L107': (.text+0xb79): undefined reference to `__stack_chk_fail_local' /usr/lib/gcc/i686-redhat-linux/4.4.4/libgcc_eh.a(unwind-dw2.o): In function `.L358':
Could you do a 'make clean' and 'make V=1' and check whether a '-fno-stack-protector' is there somewhere on the gcc command line?
Yes, I see -fno-stack-protector on the gcc calls, for example:
LD_PRELOAD=libgendep.so LD_LIBRARY_PATH=:/home/tommd/dev/L4/L4Re/build/tool/gendep/32 GENDEP_TARGET=list_alloc.s.o GENDEP_BINARY=cc1 gcc -m32 -c -DL4SYS_USE_UTCB_WRAP=1 -DSYSTEM_x86_core2_l4f -DARCH_x86 -DCPUTYPE_core2 -DL4API_l4f -D_GNU_SOURCE -I/home/tommd/dev/L4/L4Re/build/pkg/l4util/idl/OBJ-x86-l4f -I/home/tommd/dev/L4/L4Re/build/include/x86/l4f -I/home/tommd/dev/L4/L4Re/build/include/l4f -I/home/tommd/dev/L4/L4Re/build/include/x86 -I/home/tommd/dev/L4/L4Re/build/include -nostdinc -I/home/tommd/dev/L4/L4Re/build/include/x86/uclibc -I/home/tommd/dev/L4/L4Re/build/include/uclibc -I/home/tommd/dev/L4/L4Re/build/include/contrib/libstdc++-v3 -I/usr/lib/gcc/i686-redhat-linux/4.4.4/include -I/usr/lib/gcc/i686-redhat-linux/4.4.4/include-fixed -g -O2 -fno-strict-aliasing -march=core2 -Wextra -Wall -Wstrict-prototypes -Wmissing-prototypes -Wmissing-declarations -fno-common -std=gnu99 -fno-stack-protector -fPIC -U__PIC__ -D__PIC__=1 /home/tommd/dev/L4/L4Re/src/l4/pkg/l4util/lib/src/list_alloc.c -o list_alloc.s.o
Ok, guessed so. There's another one: -fno-stack-protector-all, could you add this one to GCCNOSTACKPROTOPT_f in l4/mk/Makeconf and do make oldconfig and redo? Does it make a difference? Could be this is a F13 specific thing, we'll see.
Adam
Hi,
I guess the problem is not the compilation but the used host library:
/usr/lib/gcc/i686-redhat-linux/4.4.4/libgcc_eh.a(unwind-dw2.o): In function `.L107': (.text+0xb79): undefined reference to `__stack_chk_fail_local'
Seems Fedora builds GCC with stack protection enabled. For this reason (and some others), we switched to our custom build GCC with Genode.
Cheers
Christian said:
Seems Fedora builds GCC with stack protection enabled. For this reason (and some others), we switched to our custom build GCC with Genode.
Ah, I see, thanks for the info. I might switch this dev box to Debian - this isn't the only developer-unfriendly issue I've ran into due to Fedoras design choices and/or packages.
Adam said:
I'm mainly using the codesourcery ones nowadays (4.4).
This seems to work well (built L4Re and Fiasco without a hitch). I'll be booting my ARM system and giving it a go, thanks!
Cheers, Thomas
l4-hackers@os.inf.tu-dresden.de