Forums

Help

How to specify link order of object files?

I have searched around but not found anything here. If I have a <cc> task that contains a compiler and linker specification, and at the end a fileset of say *.c, is there any way I can tell my linker to link them in a specific order? It basically just picks up all of the .obj files the compile step produces and links them in an arbitrary order. I have tried everything I can think of to manually specify the files in a certain order, and can't get it to work.

The only thing that does work is to split up the compile and link step into two separate <cc> tasks, and specify the filesets for each one. I would prefer to have it in one <cc> task however as I am autogenerating the build.xml file and it is easier this way.

It looks to me like the inherit="false" should tell the linker to not process any inherited object files, but that doesn't seem to work for me. I am specifying my linker using classname= instead of name=, because I have provided my own linker. Does the inherit boolean work for non-built-in compilers/linkers?

inherit doesn't affect the files that are presented to the linker, only the configuration of the linker. The intended use of <linker inherit="false"> is to prevent the linker from inheriting the linker configuration aspects of the <cc> element. It makes more sense with compilers since there can be multiple compilers in a <cc> element and one or more may not want to inherit include paths or something similar specified in the <cc> element.

I believe that inherit is resolved in the LinkerDef and a Linker is only presented with the fully resolved configuration. So whether the linker is built-in or custom should be immaterial.

Right. Stepping through the code, I see how this works. It looks like any linkers are going to bid on the object files produced by the compiler no matter what I do.

I think the only thing I can do is to always run two separate <cc> tasks for compiling and linking. The only drawback is I don't get the implicit linking of object files I compiled - which is nice. I'll have to manually tell the linker to *.obj basically.

It will be a rare case, but I'm fairly certain that our users will want to specify the link order of object files, and that this will be necessary. I guess I should confirm this.

One place where link order is significant is in embedded development. If you are constructing a link image that will be placed into "bank switched" rom images, you want to optimize the placement based either on size (grocery bag problem) or on frequency or reference.

Frequency of reference (function A calls B, function C calls D, so bank1 = A+B, bank2 = C+D), especially, lends itself to statically computing the layout and then using the same layout forever.

Thanks for posting, Austin. This is exactly my scenario - embedded development. I have defined my own compiler/linker for an assembly language toolchain. A lot of the time we are doing some fairly hard-coded stuff where addresses are set in stone and link order is important.

Right now I am looking at how to reliably (and extensibly) split my <cc> calls into two separate ones (compile and then link) using a fileset for each file. It seems to be the most flexible solution for me, but not the easiest to deal with in terms of generating a build file.

Actually, I have embedded cpptasks into Eclipse as a builder, and I am generating my Ant file using a custom script file generator I have made (part of my Eclipse builder code). It grabs build settings from a project-based build settings page, and auto-generates the appropriate Ant script, and runs Ant on it.