Opened 11 years ago
Last modified 10 years ago
#10771 new enhancement
Missing multilib support for libgcc-kernel
Reported by: | pulkomandy | Owned by: | korli |
---|---|---|---|
Priority: | normal | Milestone: | Unscheduled |
Component: | Build System | Version: | R1/Development |
Keywords: | Cc: | ||
Blocked By: | Blocking: | ||
Platform: | arm |
Description
We now have a separate libgcc for the kernel that disables C++11 threads support. However, the way this is built doesn't work properly with multilib compilers.
In ARM case, there are several versions of the libgcc built:
- libgcc.a (software floting point emulation, integer registers calling convention)
- fpu/libgcc.a (hardware floating point, float registers calling convention)
- soft/libgcc.a (hardware floating point, integer registers calling convention)
- thumb/libgcc.a (thumb instruction set)
- thumb/soft/libgcc.a (thumb instruction set, hardware floating point?)
- fpu/soft/libgcc.a (?)
Only the root one is considered by our libgcc-kernel build. As a result, it is not possible to build the kernel using the hardware floating point ABI. It would be nice to have at least the "fpu" version as well, and also having the others can't hurt.
Once the build-cross-tools script properly saves these libs, we will also need to modify some jam rules to make use of them. They currently always point to the default version of the library.
Was this fixed by zooey (Oliver)'s "gcc_syslibs" merge?