Hello,
In attempting to investigate building L4Re/Fiasco.OC for the Raspberry Pi Zero, I encountered an unusual problem: unusual because, I suppose, most people do not try and cross-build on architectures other than x86(-64).
When performing the initial L4Re build directory initialisation step...
make B=mybuild
...BUILD_ARCH seems to be set to x86 even on other architectures. This then causes CCXX_FLAGS to be populated with x86-dependent settings such as -m32, and the gcc host compilers for MIPS raise errors upon encountering these unrecognised arguments.
Here is the offending command in the top-level Makefile (line 376 in my version, r83 in Subversion):
GENDEP_OUTPUT=$$X.out $(CC) $(CCXX_FLAGS) -c $$X -o $$X.o
Although it seemed like the config step could be performed after ignoring these errors, I did wonder if there might be some undesirable consequences. In the end, I found that the following invocation was needed:
make B=mybuild CC=gcc CXX=g++ LD=ld BUILD_ARCH=mips CPU=32r2 CPU_ABI=32
After that, things seem to work as expected. I imagine that there is a "chicken and egg" situation here: the appropriate settings would be obtained from the configuration, but the command being run sets up the configuration.
Has anyone else seen this problem before?
Paul
Hi Paul,
On Mon Jun 10, 2019 at 16:50:57 +0200, Paul Boddie wrote:
In attempting to investigate building L4Re/Fiasco.OC for the Raspberry Pi Zero, I encountered an unusual problem: unusual because, I suppose, most people do not try and cross-build on architectures other than x86(-64).
When performing the initial L4Re build directory initialisation step...
make B=mybuild
...BUILD_ARCH seems to be set to x86 even on other architectures. This then causes CCXX_FLAGS to be populated with x86-dependent settings such as -m32, and the gcc host compilers for MIPS raise errors upon encountering these unrecognised arguments.
Here is the offending command in the top-level Makefile (line 376 in my version, r83 in Subversion):
GENDEP_OUTPUT=$$X.out $(CC) $(CCXX_FLAGS) -c $$X -o $$X.o
Although it seemed like the config step could be performed after ignoring these errors, I did wonder if there might be some undesirable consequences. In the end, I found that the following invocation was needed:
make B=mybuild CC=gcc CXX=g++ LD=ld BUILD_ARCH=mips CPU=32r2 CPU_ABI=32
After that, things seem to work as expected. I imagine that there is a "chicken and egg" situation here: the appropriate settings would be obtained from the configuration, but the command being run sets up the configuration.
Has anyone else seen this problem before?
That's a good point. You can do "make B=builddir T=arm-rv" to immediately switch to the target architecture. I'm trying to improve the handling here as I just stumpled into this in a different setting as well.
HTH, Adam
l4-hackers@os.inf.tu-dresden.de