gccNewbie wrote:
So it is really a very simple riddle. 'gcc -lmylib mysource.c' uses a function 'foo' which nm shows is defined in libmylib.a. gcc does not complain about not being able to find mylib, but it does complain that 'foo' is an 'undefined reference'. In what situation could that happen?
Linux lets you get away with this wrong link order due to lazy symbol resolution, whereas Windows does not. What you have done is asked to first link to libmylib. Since no objects (actually, you don't *have* any objects yet!) require any symbols from libmylib, no symbols are imported. Next you have asked to link 'mysource.c' (which is first compiled to object form, of course), which has unresolved symbols. And now you are at the end of the link step with unresolved symbols, which are not permitted on Windows.
The correct order is to first compile/link 'mysource.c', which (as expected) has unresolved symbols, and /then/ to link 'libmylib' which contains the unresolved symbols. Now when you reach the end of the list of things to link, you do not have unresolved symbols, and so you can successfully produce a binary.
-- Matthew "Ah, yes. Control the media and you control the world." -- from a story by Raven Blackmane
