xcode generator: object library is not able to link to binary or static lib, when two source files have the same name, since TARGET_OBJECTS does not contain the deduplicated object name
i have a project where we use multiple source-files with same name. We use subfolders ans synced namespaces to distinguish between those common names like result.cpp. Cmake does seem to handle some kind of deduplication of the names under the hood, since the object files live the in the build folder, containing an appended hash. (currently i am testing this with xcode and ios framwork generation). Generating static libs and binaries does work without any problems.
Nevertheless when i switch to object library type the following happens: $<TARGET_OBJECTS:myLib> does contain only the not-yet-deduplicated names, which leads to the situation, where the linker during consumption of the object-lib, does not find the object files. I think this is obviously a bug, since TARGET_OBJECTS should point to the really existing files.
I did write a minimal reproducer: https://github.com/cguentherTUChemnitz/cmake-objlib-dedup-bug
I am using MacOS 11.4 with XCode 12.5.1
This bug does seem only to be exposed when using the xcode generator. The other generators does seem to work fine here.
The build-folder structure and the corresponding file-name deduplication in xcode seem to expose this problem. Other generators like make are rebuilding the source-tree folder structure also for the build folder. So the object files in the build folder lives in different folders. In contrast the xcode generator produces one central folder where all object files of a single lib are placed. This results in automatic deduplication (by xcode?) where shared source filename get a hash integrated in their name. In the referenced bug-reproducer this can be found in
build/ObjLibDedupBug.build/Release/ObjLibDedupBug_lib.build/Objects-normal/x86_64 after running the compile.sh. The files listed there are looking like this:
ls build/ObjLibDedupBug.build/Release/ObjLibDedupBug_lib.build/Objects-normal/x86_64 ObjLibDedupBug_lib.LinkFileList result-fa6d7b2a3799857aafad8bd84e404aa044969acf08c7393c60180f5c6e6d4615.dia result-fa6d7b2a3799857aafad8bd84e404aa0cd8449af1d87ef1f6d57ca6988727a73.dia ObjLibDedupBug_lib_libtool_dependency_info.dat result-fa6d7b2a3799857aafad8bd84e404aa044969acf08c7393c60180f5c6e6d4615.o result-fa6d7b2a3799857aafad8bd84e404aa0cd8449af1d87ef1f6d57ca6988727a73.o result-fa6d7b2a3799857aafad8bd84e404aa044969acf08c7393c60180f5c6e6d4615.d result-fa6d7b2a3799857aafad8bd84e404aa0cd8449af1d87ef1f6d57ca6988727a73.d
Nevertheless cmake and xcode seem to be able to handle those deduplicated names for static or shared libs correctly. In constrast the object lib does contain the non-deduplicated name in $<TARGET_OBJECTS:ObjLibDedupBug_lib>, which leads to the clang linker error, where he tries to find a file, which does not exist.
+ cmake --build build --config Release --target ObjLibDedupBug -- -quiet clang: error: no such file or directory: '<escaped>/cmake-objlib-dedup-bug/build/ObjLibDedupBug.build/Release/ObjLibDedupBug_lib.build/Objects-normal/x86_64/result.o' Command Ld failed with a nonzero exit code