Why does the order of linked object file with $L directive matter?

Question

I use statically linked sqlite database and in order to compile every next version I sometimes have to do minor changes in the list of object files used. But sometimes the changes I have to make puzzles me. For example prior to version 3_6_10 this order

{$L 'Objs\is.OBJ'}
{$L 'Objs\mbisspc.OBJ'}

was ok, but starting 3_6_12 the linker said

unsatisfied forward or external declaration _isspace

but changing the order to

{$L 'Objs\mbisspc.OBJ'}
{$L 'Objs\is.OBJ'}

helped. As for the changes in sqlite, it really stopped to use c function isspace in 3_6_12 and started to use an internal equivalent so "isspace" keyword even don't appear inside the obj file.

So why does the order of linked object file with $L directive matter and where I can read more about this? I suppose it is something related to cross-usage of the listed obj files, but I will feel more safe if I understand what is going on

Thanks

Answer 1

C compilers use a multi-pass linker that knows how to resolve forward and circular dependencies between .obj files.

Since the Delphi linker is targeted at the Delphi language, and the Delphi language does not allow for that, the linker does not allow for this either.

Pro: the linker is much faster.

Con: you need to help the linker a bit by placing the .obj files in the right order.

--jeroen