OSDev.org

Hi,
It appeasrs that I am having a lot of trouble trying to get my i386-arcrascent-gcc toolchain to work .
Thanks to [sortie] again, I successfully built my toolchain and got it to work with libc - the produced executable successfully executed in my os, with all the syscall routines working properly, which made me very happy yesterday . However, I have found another issue with my toolchain. My gcc toolchain refuses to link libc by default. I always have to provide '-lc -lg -lm -lnosys' to build a program.

I have to do instead of This is very inconvenient. Also, when porting software, this issue makes it impossible for me to configure them because the configure script always complains about libc missing.
btw, I am using newlib as my libc and my gcc is v4.9.2.

How could I fix this issue?

Thanks.

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: 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.

Thank you for your response! I made some edits in Porting Newlib to work with the newer versions of newlib (i am using 2.2.0-1), and to be more compatible with the OS Specific Toolchain tutorial. I also modified OS Specific Toolchain to include the LIB_SPEC that you mentioned. I hope my edits were positive and I haven't made any errors.

Thanks!