As far as I can tell these cannot work since the linker won't find the object files if supplied like that. The gcc supplied by NXP has the right paths set as LIBRARY_PATH (e.g, /usr/local/mcuxpressoide-11.9.0_2144/ide/plugins/com.nxp.mcuxpresso.tools.linux_11.9.0.202307121226/tools/bin/../lib/gcc/arm-none-eabi/12.3.1/thumb/v7e-m+dp/hard/:...) but this does not help for linking object files because they are not search for in LIBRARY_PATH.
Instead, you have to either use a full path (e.g., /usr/local/mcuxpressoide-11.9.0_2144/ide/plugins/com.nxp.mcuxpresso.tools.linux_11.9.0.202307121226/tools/bin/../lib/gcc/arm-none-eabi/12.3.1/thumb/v7e-m+dp/hard/crtend.o) or you have to supply them via -l: (e.g., -l:crtend.o). I am not entirely sure if the latter variant is actually supposed to work - it is only documented for libraries. In any case I don't see how the current implementation in the SDK can work but maybe I am missing something...?
I've spent the last days getting C++ to work properly in my setup. Since most users of the SDK rely on the auto-generated linker scripts that contain the libraries and not even the examples using them, I am not sure if anybody is actually using the ones set by
mcux_config.cmake
, i.e., https://github.com/nxp-mcuxpresso/mcux-sdk/blob/5d978a8f88d947b8158b21557b7f997e092f79ac/tools/cmake_toolchain_files/mcux_config.cmake#L11 etc.As far as I can tell these cannot work since the linker won't find the object files if supplied like that. The gcc supplied by NXP has the right paths set as
LIBRARY_PATH
(e.g,/usr/local/mcuxpressoide-11.9.0_2144/ide/plugins/com.nxp.mcuxpresso.tools.linux_11.9.0.202307121226/tools/bin/../lib/gcc/arm-none-eabi/12.3.1/thumb/v7e-m+dp/hard/:...
) but this does not help for linking object files because they are not search for inLIBRARY_PATH
.Instead, you have to either use a full path (e.g.,
/usr/local/mcuxpressoide-11.9.0_2144/ide/plugins/com.nxp.mcuxpresso.tools.linux_11.9.0.202307121226/tools/bin/../lib/gcc/arm-none-eabi/12.3.1/thumb/v7e-m+dp/hard/crtend.o
) or you have to supply them via-l:
(e.g.,-l:crtend.o
). I am not entirely sure if the latter variant is actually supposed to work - it is only documented for libraries. In any case I don't see how the current implementation in the SDK can work but maybe I am missing something...?