porting and libs and is this really a 1 pass linker?

We are trying to port a current zlib into qnx and we are finding that the linker does not correctly resolve the contents of the archives… to the extent that we were forced to remove some modules from the archive, force them down the linkers throat and let it proceed from there. We’ve had to do this with several objects now, and on several different ports, and I am wondering if there is something special we need to do to force the linker to resolve symbols that are in the library but called out-of-order, or in object files that similarly are not quite perfectly arranged for the linkers convenience. .

Our observation to date is that neither of us have seen this sort of linker behaviour in 20 years… and just what is causing it in a relatively new (albeit known to be buggy) gcc, is not clear to us. Is there some sort of compiler/linker switch that we’ve forgotten?

respectfully
BJ

gcc and binutils are a one pass linker. So yes, if you have inner-dependancies you will have to list the libs twice to get everything resolved. Such is life with the GNU toolchain.