You want to look at LINK_SPEC in your gcc config header. I would have documented it at
OS Specific Toolchain - gcc/config/myos.h if I got that far. Sorry.
As an example,
this is how I do it for my OS. For the record, what I do is:
Code: Select all
#define LIB_SPEC "--start-group %{pthread:}-lpthread -lm -lc --end-group"
After processing the gcc spec metro-language, this becomes a string that's inserted into the linker command line. Notice the %{pthread:} magic. That's meant to pass extra options if the user passes the -pthread option, such as linking with the libpthread library. In my system, by design, pthread is always available and that compile option is not needed. I still have that magic sequence expanding to nothing for reasons I don't remember. I think it was meant to make compiler not complain when -pthread was passed, but that doesn't seem to work. So, no idea. Probably don't need it.
More interesting, it always links in libpthread, libm and libc. This is good because.. why should the user need to link against anything explicitly to use the standard library? That's silly. But a more crucial concern, however, is that libc depends on libpthread, and libpthread depends on libc. This means that with static linking you actually have to process each library multiple times, in theory a lot of such iterations might be needed to recursively drag in every single needed object file. That sucks. Instead I use the special linker options --start-group and --end-group that makes the linker do as many loops as needed. Useful! Although, I do expect to just compile all three libraries into a single libc and have empty libm and libpthread binaries for compatibility. There's no advantages to splitting them out under static linking, and I doubt it's useful under dynamic linking even.
You are a newlib user. After getting this working, please spend some love on the wiki newlib article and document this stuff.