I roughly understand that cc, ld and other parts are called in a certain sequence according to schemes like Makefiles etc. Some of those commands are used to generate those configs and Makefiles. And some other tools are used to deal with libraries. But what are other parts used for? How are they called in this process? Which tool would use various parser generators? Which part is optional? Why?

Is there a brief summary get these explained on how the tools in a GNU or LLVM/Clang toolchain are organised and called in a C/C++ project building?

Thanks in advance.


Here is a list of executables for Clang/LLVM on Mac OS X:

ar clang dsymutil gperf libtool nmedit rpcgen unwinddump as clang++ dwarfdump gprof lorder otool segedit vgrind asa cmpdylib dyldinfo indent m4 pagestuff size what bison codesign_allocate flex install_name_tool mig ranlib strip yacc c++ ctags flex++ ld mkdep rebase unifdef cc ctf_insert gm4 lex nm redo_prebinding unifdefall

  • 3
    All of those executables have documentation. Have your read it? Nov 8, 2012 at 17:33
  • Yes, just started from man pages. Some are too tedious, and I failed to get the whole picture.
    – ZhangChn
    Nov 8, 2012 at 17:37

1 Answer 1


Most of those tools are not used in a standard project - I myself have never seen half of them.

This is the basic workflow, in terms of actual processes that are run:

cc1 -> as -> collect2 -> ld

This on its own doesn't tell you all that much. There is no cpp (The preprocessor) - that is integrated into cc1. cc1 itself is the backend and the "real" compiler - the gcc binary is a frontend for all the tools that do the actual work. cc1 is the preprocessor/compiler backend, which compiles to assembly. as is the assembler, which produces object files. collect2 (I forgot about this myself, and was only made aware of it because I ran an strace) assists in arranging startup code in the executable (from here). Finally, ld links the object files and libraries into the final executable.

For the actual use of these individual components, it's generally a better idea to call gcc and let it figure out what to do. For example you can run gcc -S on a .c file to produce the .s assemply file, or gcc -E to only preprocess the source file.

Basically, man gcc is what you want to read. Or at least skim through.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.