OSDev.org

Pancakes: User-space hosted libgcc for linux will depend on stuff from the standard library, in this case you should provide most all these functions anyway (memset, memcpy, memmove and memcmp are all required unconditionally by gcc according to the documentation, even if -ffreestanding) and the rest are trivial to add.

Next, you can't and shouldn't use linux libgcc in your custom OS! (arm-linux-gnueabi is not a suitable target just like x86_64-linux-gnu isn't a suitable target for osdev, besides Linux). You need a cross-libgcc as well. The standard cross-compiler tutorial covers this and it is really simple. See Bare Bones on how to use the cross-libgcc, it's really as simple as just passing -lgcc when you link with your compiler (rather than ld). The cross-libgcc will be static unless you explicitly added shared library support to your cross-toolchain.

Note also that error means you are attempting to link in glibc into your system! That's likely very wrong. I suppose I will have to look at your tutorial carefully to see what is going on.

libgcc isn't fragile as such, you simply need to link in the correct libgcc. The fragile part is that if you clone libgcc, you will not stay in sync with the upstream libgcc and this is the fragile part.

I suppose I should do a libgcc FAQ with a better overview.

Hmm.. that makes sense. Thanks for the explanation. Yeah, I never followed a specific tutorial. I been messing around with osdev for like 10 years and just never used LIBGCC mainly because I never had a reason to make sure it was linked in until I started messing with ARM.

But, I am very happy at all the information that has come of this that can be put into the wiki!

I am the redneck programmer.. I can make it work. It just might look funny with all that duct tape on it.

I suppose I should do a libgcc FAQ with a better overview.

You know also if you can make sure people actually know that LIBGCC is important, and then know they need to read the FAQ. I bet there are a lot of people who do not even know that the library is needed because their linker never complains of any missing symbols, because the compiler just happened to not emit any symbols for it. (Me is one of them) I always targeted X86 and I just never ran into a situation where I needed LIBGCC so I never knew it existed or was needed, and I always pull the cross-compiler binaries (never by hand) so never ran across anything that said I needed it.

I took the liberty of writing a wiki article about libgcc and how to use it:

http://wiki.osdev.org/Libgcc

Please let me know if you have further questions.

I linked in the page here:
http://wiki.osdev.org/index.php?title=A ... ldid=15626

So now readers should get pushed toward LIBGCC, and if they for some reason just want to tinker around with the internals then they can read about the discussions on the forums and get a good idea of what is going on.

I think it's best if you don't say "it's recommended to use libgcc" but just say "you need to use libgcc". Experts can do without libgcc, just like they can do without a real cross-compiler - but it's bad advise to give to newbies. I'm slowly pruning all references to osdev without a cross-compiler from the wiki as it is the right way to do things and causes fewer support requests when things break; I think the same logic applies in regards to libgcc. Experts know to disregard wiki advise regardless.

Thanks for helping me link my new article to existing wiki articles.

As a side note, you almost certainly always want an 'arm-eabi' cross-compiler for ARM (rather than 'arm-elf', and definitely not 'arm-linuxeabi' ) - this will help with a variety of things, including libgcc.

Yep, Lets link it everywhere we can and it is needed. So people know about it.

No need, I have already searched the wiki for the articles that mention it and added the needed links.