2016-01-07 - ar vs. cmake

some time ago i've came across an interesting “feature” of ar¹⁾ – it does not store full paths to object files internally. instead it just keeps its name. most of the time this is not a problem. however, if you happen to have more files than command line can fit, creating archive need to be split into multiple calls: creating a libraries and then adding objects groups (multiple times, if needed). cmake does that by default. now if you happen to have object files, named the same, but stored in different directories, and try to add such objects to a static library with ar, you'll end up overwriting old object file, stored inside the archive, with a new file, that just happened to have the same name.

effect? linking error! it's extremely user fiendly²⁾ as you can clearly see your objects are being added to the archive, yet linker says implementation, stored there is missing!

the only way i could think of, to overcome this coincidence of 3 random facts/rules/limitations, is to create helper libraries, that are small enough, to be linked into a single libraries, and then add these libraries as a dependency to “final” library, so that users will not need to be aware of this implementation detail.

btw: if you think 32k is a lot, consider how long nested, auto-generated paths inside build directories, can be! it may not take that many files to trigger such behavior… but took over an hour to find. IT – every day something new! ;)