[freestanding C/C++] Unable to include crt*.o files on the linking stage in the right order

[agvallejo]

If linking with -ffreestanding the C runtime files will not be linked in. That's almost always what we want, but on some occasions while cross compiling a freestanding C++ binary with global objects, we want to link crt*.o to make sure constructors are called through _init and destructors through _fini

On traditional systems that is achieved by compiling some of the crt files ourselves (as they are different from the build machine's), taking others from the cross compiler and enforcing a linking order of the binary (to ensure crti.o and crtbegin.o come before the other objects and crtend.o and crtn.o come at the end. See end of https://dev.gentoo.org/~vapier/crt.txt).

As far as I could see there's no way to enforce said link order besides creating a generator that bypasses all compiling logic. That kind of beats the purpose of having a toolchain aware build system, so ideally Meson should be able to do either of the following:

• Enforce the link order of object files somehow: Looking at meson's design this looks like a bad idea.
• Add pre_c_link_args and post_c_llink_args: Could be done, but raises the question of how to generate the object files themselves

There's also the problem of having to having to set the last libray to -lgcc to accoount for random GCC calls to builtins, which again favours the last option.

I wouldn't mind helping out to implement this if it's within my abilities, but as you can see there are a few potential solutions. Some of which might break Meson's design intent.

[jpakkane]

How about adding a new function, such as postprocess_link_arguments in the linker object that moves the crt object files to their correct spots, if they are specified on the command line?

I can't think of a case where this would fail. Can someone?