[littlebigman]

Hello

I'm pretty much a C newbie, and am trying to learn how to compile an x86 application so it can run on an MMU-less CPU.

The toolchain uses "ar" and "ranlib", which Google tells me are used to build a library, but this article shows that gcc itself can compile a library:

Quote

gcc -c -g util.c
The -c causes the compiler to produce an object file for the library. The object file contains the library's machine code. It cannot be executed until it is linked to a program file that contains a main function. The machine code resides in a separate file named util.o.

To compile the main program, type the following:

gcc -c -g main.c

This line creates a file named main.o that contains the machine code for the main program. To create the final executable that contains the machine code for the entire program, link the two object files by typing the following:

So, when are ar/ranlib needed?

Thank you.

[JackOfAllTrades]

Did you read the man pages? man ar and man ranlib are full of information.

[littlebigman]

Yes I did, but it didn't help because it was written for people who already had enough knowledge about C.

In case some other newbie ends up on this thread looking for the same thing, here's the summary of what I found.

ar/ranlib are used specifically to build static libraries, where "ar" compiles the object files (.o) into a single library file (.a) while "ranlib" is used to build the symbol table for all the objects from the archive ("Once you are satisfied with the contents of an object library, you should randomize it with the ranlib command to improve the loader's access time when it loads the library with other source code files." source)

Modern build systems use libtools, so ar/ranlib seems to only be used today to build libraries on embedded systems.

HTH,

[Oler1s]

Not quite.

gcc either drives it's compiling programs or the linker. If you have source files, you get object files for each, like util.o for util.c . Let's say you have a 1000 source files. You get a 1000 object files to use. Then you can link the 1000 object files together to create the program. Not bad.

Unless you didn't have a program and your code represented a library. Walking around with a 1000 object files stinks. You want a single file representing an archive. Either it's intended to be linked at compile time (static linking) or loaded at run time (dynamic linking). So gcc can't help here.

ar is used to do the packaging for a static library. With ar, you can push all object files into a single archive. Or multiple archives together. So instead of a 1000 source files, you get a single archive, which you can use with gcc.

This archive needs an index for gcc to make use of. So, ranlib can do that. Often ar can do it too, so ranlib just exists for history sake.

libtool is sort of like a convenience tool. It's a bit messy to work directly with ar and ranlib, and gcc, and ld, so libtool works as an easy way to create the libraries. It may just use ar and ranlib behind the scenes.

[littlebigman]

Thanks for the clarification/confirmation of what I thought I understood.

Man pages are useful to get the details about a specific command, but are not that useful to get the big picture, which was what I needed to go forth.

Thank you.

This post has been edited by littlebigman: 24 November 2010 - 09:45 AM