Home/ Questions/Q 1116015
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-05-17T03:14:28+00:00

I’m going to use a small example for reference. Consider a project with: inner_definitions.o

  • 0

I’m going to use a small example for reference. Consider a project with:

inner_definitions.o : inner_definitions.cpp inner_definitions.h
    gcc $^ -o $@

inner_class_1.o : inner_class_1.cpp inner_class_1.h inner_definitions.h
    gcc $^ -o $@    

inner_class_2.o : inner_class_2.cpp inner_class_2.h inner_definitions.h
    gcc $^ -o $@

outer_class.o : outer_class.cpp outer_class.h inner_class_1.h inner_class_2.h
    gcc $^ -o $@

executable.o : executable.cpp executable.h outer_class.h
    gcc $^ -o $@

executable : __?1__
    __?2__

But filling in the blanks __?1__ for the linker dependencies and __?2__ for the linker command isn’t easy.

In this small example, one could argue that its easy to see that __?1__ = inner_definitions.o inner_class_1.o inner_class_2.o outer_class.o executable.o . However, this is clearly not a scalable solution as it forces each developer to understand all the dependencies of the code they are working with so they can figure out the dependencies by hand rather than by using the make utility.

Another solution would be to have a different variable for each object file that listed all its downstream dependencies: i.e __?1__ = executable.o $(executable_dependencies). This is not a desired solution because it forces the makefile to be compiled in the specific way so the variables are only used when they are fully defined. Also, for really large applications these variables might exceed the maximum variable length.

Yet another solution is to use archive .a files for linking. In this case, we could construct an inner_class_1.a that included both inner_defintions.o and inner_class_1.o, so it could be linked with any object file that needed inner_class_1.o without forcing the developer to reconstruct the dependencies. This approach seems promising, but involves having many duplicate files. Also, it doesn’t appear that the gcc linker can handle nested archive files.

Is there another approach? What is the best approach? Can the gcc linker handle nested archive files?

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    The job you’re trying to automate (picking the right object files to satisfy all references) is usually left to the linker, using static libraries (“.a” files) to group the candidate object files, just as you suggest.

    An important detail you may be missing: If you pass the linker an archive, it will only link in those files from the archive that are actually needed. So you can create archives at a fairly coarse level of granularity without necessarily bloating all your executables — the linker will pick just what it needs — although can easily end up with needlessly slow builds if you take this approach too far.

    The GNU linker will not pull objects out of nested libraries. If you want to make one big library by merging many small ones, you can do that with the “addlib” command in an ar script. That will give you a single archive containing all of the object files without any nested library structure.

    If the duplication of having .o files and .a files containing the same object code lying around bothers you, the fine manual describes a way to have make update the archives “directly”.

    • 0