Hello,
I finally got round to looking at L4/Fiasco.OC again, and having previously looked at the MIPS32 port that was made available on GitHub...
https://github.com/MIPS/fiasco-l4re
...I have been attempting to cross-compile Fiasco and L4Re using the l4re.org sources. Getting Fiasco to cross-compile was mostly a matter of repeating the same procedure as last time:
cd src/kernel/fiasco make BUILDDIR=mybuild cd mybuild/ make config make
However, I needed to edit src/kernel/fiasco/src/Makeconf.mips32 to change the compiler settings. I'm using the toolchains in Debian unstable:
CROSS_COMPILE ?= mipsel-linux-gnu-
Previously, I used a Makeconf.local file to set the following:
SYSTEM_TARGET=mipsel-linux-gnu- SHARED_FLAGS=-mips32r2 -EL -msoft-float -mno-abicalls -fno-pic
Maybe the previous work used some different mechanisms to those used by the more general source distribution, but this trick didn't seem to influence the build successfully this time around. However, the build did complete successfully with the toolchain set appropriately.
Meanwhile, I had more problems with the L4Re part. I had expected to be able to do the following:
cd src/l4 make B=mybuild make O=mybuild config make O=mybuild E=mips-fbspectrum
(The target was something that I had managed to build previously after some messing around with packages and configuration files. I'd managed to build the fbspectrum example for Fiasco.OC-UX, as the list archives will attest.)
However, I also had to change the compiler settings (as done above) in src/l4/mk/arch/Makeconf.mips, instead of using src/l4/Makeconf.local (as done previously). Again, maybe the way of doing things was different in the previous incarnation of this port.
I also needed to edit src/l4/tool/gendep/syscall.c to add a definition before unistd.h gets included:
#define __ARCH_WANT_SYSCALL_NO_AT
I can't remember if I or anyone else has mentioned this before now, but without it, things like __NR_open are not defined.
Unfortunately, I haven't yet reached a satisfactory conclusion in this latter exercise. Looking back at my previous messages, it seems that a bit more work might be needed to configure and build a suitable target, and so I was wondering if anyone had done this (and written it up) for any of the MIPS boards, perhaps the CI20. Indeed, I wonder if things like the framebuffer are even supported for the CI20 or other MIPS boards.
Paul
Hi Paul,
On Sun Jun 12, 2016 at 01:19:26 +0200, Paul Boddie wrote:
Please use CROSS_COMPILE=mipsel-linux-gnu- here.
SHARED_FLAGS=-mips32r2 -EL -msoft-float -mno-abicalls -fno-pic
Setting SHARED_FLAGS flags is not required (actually must not, otherwise I'd regard this as a bug).
Also use CROSS_COMPILE here.
On which system are you compiling this? This doesn't happen for us, so I'm wondering.
We do not have any support for framebuffers on MIPS targets yet.
Adam
On Monday 13. June 2016 00.41.12 Adam Lackorzynski wrote:
OK. CROSS_COMPILE did work, but I thought I'd mention that the SYSTEM_TARGET variable was apparently what the fiasco-l4re documentation was suggesting. Given that nobody involved in doing that work seems to have anything to say about it, I thought I'd mention it here.
(I'd have more confidence in the things Imagination Technologies produce - or commission for their use - if they gave more of an indication that they support those things, particularly over a reasonable timeframe.)
Right. That would be consistent with the above and with the Makeconf files. I guess Makeconf.local might be supported, given that there did seem to be a mention of extra files in the configuration system, but in a version controlled environment it is just as easy to modify the distributed configuration, anyway.
I'm compiling in a Debian unstable chroot on i386. Are you still using i386 to build with? Recent experiences with other projects indicate that support for i386 sometimes falls behind amd64, although I have no idea or immediate recollection why the unistd.h behaviour changed as indicated above.
OK. This gets me back to the point I was before, but since then I've gained a bit more experience with the hardware involved, which isn't the CI20 but does feature a related Ingenic jz47xx-series CPU.
Thanks for the advice!
Paul
On Mon Jun 13, 2016 at 12:50:07 +0200, Paul Boddie wrote:
Even better, the code has been merged and life went on. Since then we have changed to use CROSS_COMPILE and deprecated SYSTEM_TARGET (unfortunately the compat code and the deprecation message are placed before Makeconf.local files are included, thus that does not work in your case).
Sure, but Makeconf.local will also work.
Although amd64 is in the majority, i386 is still in the game, and I've never seen this before. Also, __NR_open is not used directly, thus my question, where is it missing?
Ok.
Adam
On Tuesday 14. June 2016 00.16.35 Adam Lackorzynski wrote:
In src/l4/tool/gendep/syscall.c there is this include:
#include <unistd.h>
(There are actually two of them.) This header eventually includes the following file:
/usr/include/asm-generic/unistd.h
This is provided by the following packages:
linux-libc-dev:i386, linux-libc-dev:mipsel
In the file in question, I see the following...
/* * All syscalls below here should go away really, * these are provided for both review and as a porting * help for the C library version. * * Last chance: are any of these important enough to * enable by default? */ #ifdef __ARCH_WANT_SYSCALL_NO_AT #define __NR_open 1024 __SYSCALL(__NR_open, sys_open)
Now, I imagine that the "at-less" syscalls are deprecated (according to some definition of the word, maybe only for the Linux people), but perhaps this decision isn't exposed in other distributions. But I really don't know why this is a problem only for me.
Paul
On Wednesday 15. June 2016 23.30.47 Adam Lackorzynski wrote:
make O=mybuild config scripts/kconfig/mconf /home/paulb/L4-for- MIPS/l4re.org/src/l4/mybuild/Kconfig.generated
*** End of the configuration. *** Execute 'make' to start the build or try 'make help'.
scripts/kconfig/conf --silentoldconfig /home/paulb/L4-for- MIPS/l4re.org/src/l4/mybuild/Kconfig.generated All build tools checked ok. gcc -fPIC -Wall -pedantic -g -m32 -c /home/paulb/L4-for- MIPS/l4re.org/src/l4/tool/gendep/syscall.c -o /home/paulb/L4-for- MIPS/l4re.org/src/l4/mybuild/tool/gendep/syscall.32.o mkdir -p /home/paulb/L4-for-MIPS/l4re.org/src/l4/mybuild/tool/gendep/32 gcc -m32 -shared -Wl,--no-as-needed -Wl,-soname,/home/paulb/L4-for- MIPS/l4re.org/src/l4/mybuild/tool/gendep/32/libgendep.so -ldl -o /home/paulb/L4-for-MIPS/l4re.org/src/l4/mybuild/tool/gendep/32/libgendep.so /home/paulb/L4-for-MIPS/l4re.org/src/l4/mybuild/tool/gendep/deptrack.32.o /home/paulb/L4-for-MIPS/l4re.org/src/l4/mybuild/tool/gendep/syscall.32.o gcc -fPIC -Wall -pedantic -g -m64 -c /home/paulb/L4-for- MIPS/l4re.org/src/l4/tool/gendep/syscall.c -o /home/paulb/L4-for- MIPS/l4re.org/src/l4/mybuild/tool/gendep/syscall.64.o In file included from /usr/include/sys/syscall.h:31:0, from /home/paulb/L4-for- MIPS/l4re.org/src/l4/tool/gendep/syscall.c:21: /home/paulb/L4-for-MIPS/l4re.org/src/l4/tool/gendep/syscall.c: In function 'real_open': /home/paulb/L4-for-MIPS/l4re.org/src/l4/tool/gendep/syscall.c:52:19: error: '__NR_open' undeclared (first use in this function) return (syscall(SYS_open, (fn), (flags), (mode))); ^ /home/paulb/L4-for-MIPS/l4re.org/src/l4/tool/gendep/syscall.c:52:19: note: each undeclared identifier is reported only once for each function it appears in /home/paulb/L4-for-MIPS/l4re.org/src/l4/tool/gendep/syscall.c: In function 'real_unlink': /home/paulb/L4-for-MIPS/l4re.org/src/l4/tool/gendep/syscall.c:172:18: error: '__NR_unlink' undeclared (first use in this function) return syscall(SYS_unlink, (fn)); ^ /home/paulb/L4-for-MIPS/l4re.org/src/l4/tool/gendep/syscall.c: In function 'real_open': /home/paulb/L4-for-MIPS/l4re.org/src/l4/tool/gendep/syscall.c:53:1: warning: control reaches end of non-void function [-Wreturn-type] } ^ /home/paulb/L4-for-MIPS/l4re.org/src/l4/tool/gendep/syscall.c: In function 'real_unlink': /home/paulb/L4-for-MIPS/l4re.org/src/l4/tool/gendep/syscall.c:173:1: warning: control reaches end of non-void function [-Wreturn-type] } ^ Makefile:48: recipe for target '/home/paulb/L4-for- MIPS/l4re.org/src/l4/mybuild/tool/gendep/syscall.64.o' failed make[4]: *** [/home/paulb/L4-for- MIPS/l4re.org/src/l4/mybuild/tool/gendep/syscall.64.o] Error 1 Makefile:404: recipe for target 'libgendep' failed make[3]: *** [libgendep] Error 2 Makefile:232: recipe for target 'DROPSCONF_CONFIG_MK_POST_HOOK' failed make[2]: *** [DROPSCONF_CONFIG_MK_POST_HOOK] Error 2 mk/config.inc:122: recipe for target '/home/paulb/L4-for- MIPS/l4re.org/src/l4/mybuild/.config.all' failed make[1]: *** [/home/paulb/L4-for-MIPS/l4re.org/src/l4/mybuild/.config.all] Error 2 mk/config.inc:89: recipe for target 'config' failed make: *** [config] Error 2
On Thu Jun 16, 2016 at 00:10:50 +0200, Paul Boddie wrote:
Do you have linux-libc-dev:amd64 installed? If not, please do.
Adam
On Monday 20. June 2016 23.01.51 Adam Lackorzynski wrote:
Is this necessary if I'm using the i386 host architecture in Debian? I think I posted the following earlier:
dpkg -S /usr/include/asm-generic/unistd.h linux-libc-dev:i386, linux-libc-dev:mipsel: /usr/include/asm-generic/unistd.h
So, I have two architecture variants of the package installed already.
Although architecture-specific unistd.h files are provided by a surprising number of packages [*], I don't see any difference in behaviour between them with regard to this issue. For example:
diff /usr/mipsel-linux-gnu/include/asm-generic/unistd.h /usr/include/asm- generic/unistd.h 715a716,723
718c726 < #define __NR_syscalls 284 ---
#define __NR_syscalls 288
They both exclude the required definitions without __ARCH_WANT_SYSCALL_NO_AT.
Paul
[*] https://packages.debian.org/search?searchon=contents&keywords=gnu%2Fincl... generic%2Funistd.h&mode=path&suite=unstable&arch=any
On Tue Jun 21, 2016 at 00:42:38 +0200, Paul Boddie wrote:
The build system is building host tooling for both 32 and 64 bit binaries as x86-based host systems will run both variants quite happily nowadays. The goal was to allow using (older) 32bit-only cross compilers on 64bit systems (and vice versa). I'm trying to get rid of this now. In the meantime you could install the package I recommend, or alternatively, edit l4/tool/gendep/Makefile and remove $(LIB64) from the LIB assignment.
Adam
On Wednesday 22. June 2016 00.24.59 Adam Lackorzynski wrote:
Right, the linux-libc-dev:amd64 dependency makes a bit more sense in this context. I decided to remove the LIB64 reference instead, since I don't particularly want to mess around too much with multiple architectures, and the problem seems to be resolved when I "make ... config".
Thanks for looking into this! I guess I'm one of the few people still trying to do things like this on i386 (on Debian).
Paul
l4-hackers@os.inf.tu-dresden.de
-
Adam Lackorzynski -
Paul Boddie