Hi Ramirez, > What is the order criteria? The GCC tool chain driver processes items left to right. Object files (or source files which compile to object files) are always taken in their entirety. Archive libraries only bring in the objects from within the archive that satisfy missing symbols. If archive libfoo.a has undefined symbols that are satisfied in libbar.a, then libbar.a needs to appear after libfoo.a. Regardless if they are specified via -lfoo -lbar, or libfoo.a libbar.a or -lfoo libbar.a or libfoo.a -libbar.a. Shared object libraries are brought in as SSO (static shared object) as specified on the command line. An SSO may have its own dependencies. NOTE: if you bring in a shared object library programmatically, that's called a DSO (dynamic shared object). There are some situations where there is both a libfoo.a and libfoo.so. If left to -lfoo to resolve, the one that is brought in is dependent on your particular platform and if you overrode the platform bias. Note: I'm using "libfoo.a" and "libfoo.so", but you may have a platform like the Amiga that uses "foo.a" and "foo.library", or Windows which uses "foo.lib" and "foo.dll", or OS X which uses "libfoo.a" and "libfoo.dylib". So your mileage may vary. The rule of thumb is: specify all your .o files first (in any order) specify all your .a and .so libraries in their dependency order And if you are running into a circular dependency between libfoo.a and libbar.a, you'll have to do something utterly horrible like... g++ -o myapp one.o two.o three.o -lfoo -lbar -lfoo HTH, --Eljay
