Latest version of Xcode broke Corrade

[AndySomogyi]

Hey, looks like the newest version of Xcode broke Corrade. Seems to build OK with Eclipse, but Xcode build fails.

I'm just starting to look into it, but here's what I get

Libtool /Users/andy/src/mx-xcode/extern/corrade/src/Corrade/Utility/Debug/libCorradeUtility-d.a normal x86_64 (in target: CorradeUtility)
    cd /Users/andy/src/mechanica
    export MACOSX_DEPLOYMENT_TARGET=10.13
    /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/libtool -static -arch_only x86_64 -syslibroot /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.14.sdk -L/Users/andy/src/mx-xcode/extern/corrade/src/Corrade/Utility/Debug -filelist /Users/andy/src/mx-xcode/extern/corrade/src/Corrade/Utility/Mechanica.build/Debug/CorradeUtility.build/Objects-normal/x86_64/CorradeUtility-d.LinkFileList 
/Users/andy/src/mx-xcode/extern/corrade/src/Corrade/Utility/Mechanica.build/Debug/CorradeUtilityObjects.build/Objects-normal/undefined_arch/Debug.o 
/Users/andy/src/mx-xcode/extern/corrade/src/Corrade/Utility/Mechanica.build/Debug/CorradeUtilityObjects.build/Objects-normal/undefined_arch/Directory.o 
/Users/andy/src/mx-xcode/extern/corrade/src/Corrade/Utility/Mechanica.build/Debug/CorradeUtilityObjects.build/Objects-normal/undefined_arch/Configuration.o 
/Users/andy/src/mx-xcode/extern/corrade/src/Corrade/Utility/Mechanica.build/Debug/CorradeUtilityObjects.build/Objects-normal/undefined_arch/ConfigurationValue.o 
/Users/andy/src/mx-xcode/extern/corrade/src/Corrade/Utility/Mechanica.build/Debug/CorradeUtilityObjects.build/Objects-normal/undefined_arch/MurmurHash2.o 
/Users/andy/src/mx-xcode/extern/corrade/src/Corrade/Utility/Mechanica.build/Debug/CorradeUtilityObjects.build/Objects-normal/undefined_arch/Sha1.o 
/Users/andy/src/mx-xcode/extern/corrade/src/Corrade/Utility/Mechanica.build/Debug/CorradeUtilityObjects.build/Objects-normal/undefined_arch/System.o -o 
/Users/andy/src/mx-xcode/extern/corrade/src/Corrade/Utility/Debug/libCorradeUtility-d.a

error: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/libtool: can't open file: /Users/andy/src/mx-xcode/extern/corrade/src/Corrade/Utility/Mechanica.build/Debug/CorradeUtilityObjects.build/Objects-normal/undefined_arch/Debug.o (No such file or directory)
error: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/libtool: can't open file: /Users/andy/src/mx-xcode/extern/corrade/src/Corrade/Utility/Mechanica.build/Debug/CorradeUtilityObjects.build/Objects-normal/undefined_arch/Directory.o (No such file or directory)
error: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/libtool: can't open file: /Users/andy/src/mx-xcode/extern/corrade/src/Corrade/Utility/Mechanica.build/Debug/CorradeUtilityObjects.build/Objects-normal/undefined_arch/Configuration.o (No such file or directory)
error: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/libtool: can't open file: /Users/andy/src/mx-xcode/extern/corrade/src/Corrade/Utility/Mechanica.build/Debug/CorradeUtilityObjects.build/Objects-normal/undefined_arch/ConfigurationValue.o (No such file or directory)
error: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/libtool: can't open file: /Users/andy/src/mx-xcode/extern/corrade/src/Corrade/Utility/Mechanica.build/Debug/CorradeUtilityObjects.build/Objects-normal/undefined_arch/MurmurHash2.o (No such file or directory)
error: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/libtool: can't open file: /Users/andy/src/mx-xcode/extern/corrade/src/Corrade/Utility/Mechanica.build/Debug/CorradeUtilityObjects.build/Objects-normal/undefined_arch/Sha1.o (No such file or directory)
error: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/libtool: can't open file: /Users/andy/src/mx-xcode/extern/corrade/src/Corrade/Utility/Mechanica.build/Debug/CorradeUtilityObjects.build/Objects-normal/undefined_arch/System.o (No such file or directory)
Command Libtool failed with a nonzero exit code

[AndySomogyi]

However, upgrading to latest version of CMake seems to resolve the issue.

Upgraded cmake 3.11.4 -> 3.12.2 and that seems to have resolved the issue. Looks like it was something wonky with Xcode, not sure what caused the issue, but FYI.

[AndySomogyi]

Maybe put a check in if Xcode build, minimum cmake required is 3.12.2. Might work on older versions, not sure, but 3.12.2 fixed the issue for me.

[mosra]

Hi, thanks for the report! 👍

Would you have a chance to test if this is a problem just specific to Corrade? I have no way to test this myself, but to me it looks like it's a general issue where older CMake won't work with latest Xcode -- not being specific to Corrade -- especially the weird /undefined_arch/ part.

If it's really a general issue, I don't think putting a Xcode-specific warning / error there is a good idea (all CMake-based projects would have to do that, then). If it's caused by something specific to Corrade, then yes, I'm all for it.

[AndySomogyi]

As far as I can tell, this issue was specific to Corrade. I've tested the old version of CMake with newer Xcode and all the other projects built fine. Furthermore, it is specific to older CMake, and only Xcode build. The older CMake built the Corrade project just fine when I told it to make an Eclipse project.

The extent of my troubleshooting was:

• noticed Corrade wouldn't build after "upgrading" Xcode.
• tried Corrade by itself and CMake-XCode - wouldn't built.
• tried Corrade with CMake-Eclipse - worked just fine.
• tried CMake-XCode with other projects worked fine.
• pulled Corrade - Magnum from GitHub -- no change, still had issue with Xcode project.
• figured, lets try to upgrade CMake, see what happens. Sure enough, that resolved the problem, so I stopped looking.

I don't really have a way of re-testing it with new Xcode and older CMake because I upgraded CMake, and I'm under a lot of pressure to get this thing I'm working on working.

But in any case, as far as I can tell, for me, the problem was specific to the combination of (Corrade, older CMake, new Xcode).

[AndySomogyi]

Also, with the new version of CMake, it never tries to make the undefined_arch directory, the build directory with new CMake and Xcode project looks like:

Andy-MacBook-Pro:CorradeUtility.build andy$ pwd
/Users/andy/src/mx-xcode/extern/corrade/src/Corrade/Utility/Mechanica.build/Debug/CorradeUtility.build
Andy-MacBook-Pro:CorradeUtility.build andy$ tree
.
├── Objects-normal
│   └── x86_64
│       ├── Arguments.d
│       ├── Arguments.dia
│       ├── Arguments.o
│       ├── ConfigurationGroup.d
│       ├── ConfigurationGroup.dia
│       ├── ConfigurationGroup.o
│       ├── CorradeUtility-d.LinkFileList
│       ├── Format.d
│       ├── Format.dia
│       ├── Format.o
│       ├── Resource.d
│       ├── Resource.dia
│       ├── Resource.o
│       ├── String.d
│       ├── String.dia
│       ├── String.o
│       ├── Unicode.d
│       ├── Unicode.dia
│       └── Unicode.o
├── StaticAnalyzer
│   └── Mechanica
│       └── CorradeUtility
│           └── normal
│               └── x86_64
│                   ├── Arguments.d
│                   ├── Arguments.plist
│                   ├── ConfigurationGroup.d
│                   ├── ConfigurationGroup.plist
│                   ├── Format.d
│                   ├── Format.plist
│                   ├── Resource.d
│                   ├── Resource.plist
│                   ├── String.d
│                   ├── String.plist
│                   ├── Unicode.d
│                   └── Unicode.plist
├── dgph
└── dgph~

[mosra]

I'm under a lot of pressure to get this thing I'm working on working

I totally understand that ;) My case right now as well. Thus thank you a lot for taking the extra time to report this.

I bet this is due to my use of OBJECT libraries (since that's not so common) and I think I could dig through CMake commit log to see what particular change that went into 3.12.2 fixed this and once I have it, I could either invent a workaround or end with an error, as you suggested. However, I don't want to globally require latest CMake for all Xcode versions (some clients are deliberately on older Xcode versions and requiring newer CMake may break their workflow) -- so I'd like to issue the error message/workaround only for the affected Xcode version.

So my final question: what's your Xcode version? Or even better, what does CMake report as detected compiler version? Should be something like AppleClang 9.9.

[AndySomogyi]

I've dumped some CMake vars, here they are.

I think it's probably sufficient to check for XCODE_VERSION >= 10.0 and CMAKE_GENERATOR == Xcode

CMAKE_SYSTEM_NAME: Darwin
CMAKE_OSX_DEPLOYMENT_TARGET: 10.13
MACOSX_DEPLOYMENT_TARGET:
CMAKE_OSX_SYSROOT: /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.14.sdk
XCODE_VERSION: 10.0
CMAKE_GENERATOR: Xcode
CMAKE_CXX_COMPILER_ID: Clang
CMAKE_CXX_COMPILER_VERSION: 10.0.0.10001145

[mosra]

Managed to track this down to https://gitlab.kitware.com/cmake/cmake/issues/18099 (so CMake 3.12.0 has the fix already, it seems). Since a14b1ae I am failing early with an error, suggesting users to upgrade. If you would have a chance to verify it works as intended, I would be happy :)