Somebody claiming to be Joe Nelson wrote: > Hi Dave and Tracey, seems like you have experience in this area. Can you give > me any advice? > > I'm cross-compiling for an ST Nucleo F411RE, which requires these CFLAGS: > > -mcpu=cortex-m4 -mthumb -mfloat-abi=hard -mfpu=fpv4-sp-d16 > > On my system, 'arm-none-eabi-gcc -print-multi-directory' can't find a match > for > them. By comparison, on Debian, arm-none-eabi-gcc finds 'thumb/v7e-m+fp/hard'. > > Is there a way to update the port on my system to include this multilib > flavor?
The arm-none-eabi-gcc you have might be able to build working binaries anyways; code generation isn't affected, and the thumb builds of the libraries it has will still very probably work, but you won't have library support for newer features of the Cortex-M4 core. (Also, notably, the library configuration doesn't know about thumb- only cores and builds a few libgcc routines that use arm-mode instructions and won't work - but the only place I've seen that happen is a software division call that the M4 has hardware instructions for.) If that doesn't work, the patch at https://marc.info/?l=openbsd-ports&m=159897831109275&w=2 enables the R/M profile multilib options to get library support for Cortex-M cores. (The binutils part of the patch there is already committed; newlib configures itself based on the GCC multilib config, so it needs an update to get support for the ARMv8 configurations as well as a rebuild to pick up the new config.) (The reasons why this is necessary for Cortex-M cores and not already in the ports tree are complicated but round to "ARM multilib config is complicated, and this port is critical system infrastructure in a way that does not care about embedded cross-compiling".) dave -- Dave Vandervies dj3va...@terse.ca Plan your future! Make God laugh!
