CPPLib_log error when building with Xcode

Filed SR-14768.

https://bugs.swift.org/browse/SR-14768

1 Like

I omitted the test flag but same issue unfortunately:

tils/build-script --skip-build-benchmarks \
  --skip-ios --skip-watchos --skip-tvos --swift-darwin-supported-archs "$(uname -m)" \
  --sccache --release-debuginfo --swift-disable-dead-stripping \
  --xcode --clean

R.E this workaround:

Update: now the workaround has been updated to refer to a different line, it works!
This only removed one of the errors for me unfortunately (sorry I accidentally closed the log so don't have more details), though I wasn't using --debug-swift flag if that makes any difference. I'm building now to see if removing the logging line from Klass.swift works as an alternate workaround.

I'll take a look. I have a feeling (without looking BTW so I could be wrong) about what the solution is.

EDIT: Also thanks for the bug report!

1 Like

Just an update to this: I ran the following command after removing the logging line from the Klass file:

utils/build-script --skip-build-benchmarks \
  --skip-ios --skip-watchos --skip-tvos --swift-darwin-supported-archs "$(uname -m)" \
  --sccache --release-debuginfo --swift-disable-dead-stripping \
  --xcode --clean

While this removed the Klass errors, my build failed later, not sure if related to me removing the logging line but thought I'd share just in case... Given this has to do with a test target, I'll try adding --test back to see if that fixes anything. Update: It did not fix anything

Ld /Users/jackmarch/swift-project/build/Xcode-RelWithDebInfoAssert/swift-macosx-x86_64/RelWithDebInfo/lib/libTestPureSwiftSharedLib.dylib normal (in target 'TestPureSwiftSharedLib' from project 'Swift')

cd /Users/jackmarch/swift-project/swift

/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/clang -target x86_64-apple-macos11.3 -dynamiclib -isysroot /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX11.3.sdk -L/Users/jackmarch/swift-project/build/Xcode-RelWithDebInfoAssert/swift-macosx-x86_64/RelWithDebInfo/lib -L/Users/jackmarch/swift-project/build/Xcode-RelWithDebInfoAssert/llvm-macosx-x86_64/RelWithDebInfo/lib/RelWithDebInfo -L/Users/jackmarch/swift-project/build/Xcode-RelWithDebInfoAssert/llvm-macosx-x86_64/RelWithDebInfo/lib -L/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/lib/swift/macosx/RelWithDebInfo -L/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/lib/swift/macosx -F/Users/jackmarch/swift-project/build/Xcode-RelWithDebInfoAssert/swift-macosx-x86_64/RelWithDebInfo/lib -filelist /Users/jackmarch/swift-project/build/Xcode-RelWithDebInfoAssert/swift-macosx-x86_64/validation-test/BuildSystem/swift-cmake/Swift.build/RelWithDebInfo/TestPureSwiftSharedLib.build/Objects-normal/x86_64/TestPureSwiftSharedLib.LinkFileList -install_name @rpath/libTestPureSwiftSharedLib.dylib -Xlinker -object_path_lto -Xlinker /Users/jackmarch/swift-project/build/Xcode-RelWithDebInfoAssert/swift-macosx-x86_64/validation-test/BuildSystem/swift-cmake/Swift.build/RelWithDebInfo/TestPureSwiftSharedLib.build/Objects-normal/x86_64/TestPureSwiftSharedLib_lto.o -fobjc-link-runtime -L/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/lib/swift/macosx -L/usr/lib/swift -Xlinker -add_ast_path -Xlinker /Users/jackmarch/swift-project/build/Xcode-RelWithDebInfoAssert/swift-macosx-x86_64/validation-test/BuildSystem/swift-cmake/Swift.build/RelWithDebInfo/TestPureSwiftSharedLib.build/Objects-normal/x86_64/TestPureSwiftSharedLib.swiftmodule -Xlinker -compatibility_version -Xlinker 1 -import-objc-header /Users/jackmarch/swift-project/swift/validation-test/BuildSystem/swift-cmake/CPPLib.h -dynamiclib /Users/jackmarch/swift-project/build/Xcode-RelWithDebInfoAssert/swift-macosx-x86_64/RelWithDebInfo/lib/libTestCPPLib.a -lc++ -Xlinker -no_adhoc_codesign -Xlinker -dependency_info -Xlinker /Users/jackmarch/swift-project/build/Xcode-RelWithDebInfoAssert/swift-macosx-x86_64/validation-test/BuildSystem/swift-cmake/Swift.build/RelWithDebInfo/TestPureSwiftSharedLib.build/Objects-normal/x86_64/TestPureSwiftSharedLib_dependency_info.dat -o /Users/jackmarch/swift-project/build/Xcode-RelWithDebInfoAssert/swift-macosx-x86_64/RelWithDebInfo/lib/libTestPureSwiftSharedLib.dylib

clang: error: unknown argument: '-import-objc-header'

clang: error: cannot specify -o when generating multiple output files

Command Ld failed with a nonzero exit code

**** BUILD FAILED ****

The following build commands failed:

Ld /Users/jackmarch/swift-project/build/Xcode-RelWithDebInfoAssert/swift-macosx-x86_64/RelWithDebInfo/lib/libTestPureSwiftSharedLib.dylib normal

(1 failure)

ERROR: command terminated with a non-zero exit status 65, aborting

Given your output paths /Users/jackmarch/swift-project/build/Xcode-RelWithDebInfoAssert/swift-macosx-x86_64/validation-test/ it is still trying to build validation tests... which to me (but I may don't fully understand the changes on cmake) it should not happen if you comment https://github.com/apple/swift/blob/e731f013ceb12acb744f842fb3a4ef38d9c21c10/CMakeLists.txt#L1074

Edit: I just noted that the link on the comment of GitHub was pointing to the wrong line ..., just fixed =]

the new line you've suggested to comment out instead has worked like a charm, cheers Luciano!

1 Like

Is commenting add_subdirectory(validation-test) likely the reason so many of the tests are failing when I try to run them @LucianoPAlmeida ? (Note I changed the path from Ninja to Xcode, not sure if this is the reason as it says "warning: Building Xcode project is not supported yet. Skipping..."):

swift % utils/run-test --lit ../llvm-project/llvm/utils/lit/lit.py \
  ../build/Xcode-RelWithDebInfoAssert/swift-macosx-$(uname -m)/test-macosx-$(uname -m)
Testing Time: 377.40s
  Unsupported      :  275
  Passed           :  540
  Expectedly Failed:   25
  Failed           : 6138

Has errors about swift-frontend not found:

/Users/jackmarch/swift-project/build/Xcode-RelWithDebInfoAssert/swift-macosx-x86_64/test-macosx-x86_64/APINotes/Output/type_changes.swift.script: line 1: swift-frontend: command not found

Running tests from Xcode in check-swift-all target doesn't work either, e.g. errors like:

In file included from /Users/jackmarch/swift-project/swift/unittests/Localization/SerializationTests.cpp:13:
/Users/jackmarch/swift-project/swift/unittests/Localization/LocalizationTest.h:26:10: fatal error: 'gtest/gtest.h' file not found
#include "gtest/gtest.h"
^~~~~~~~~~~~~~~
1 error generated.

Normally you run lit tests against a ninja build. So you build Xcode to work on a nice IDE, and for running lit tests you use a ninja build that I normally use:

// Ninja Build command

./swift/utils/build-script --release --skip-build-benchmarks --swift-darwin-supported-archs 'x86_64' --sccache --skip-ios --skip-tvos --skip-watchos

// And then for Testing
llvm-project/llvm/utils/lit/lit.py -sv --param swift_site_config=build/Ninja-ReleaseAssert/swift-macosx-x86_64/test-macosx-x86_64/lit.site.cfg swift/test/

Note that the folder x86_64 may be different if you are building on a M1 Mac ...
But for lit tests I always used the ninja build, because as far as I know it will not work on Xcode one ... so in short you have to build both ninja and Xcode, and run lit against the ninja one =]

This target I think will run the UnitTests(cpp unit tests under unittests folder) not the test/** that we run using lit. But this error is already tracked on an issue [SR-14352] Xcode fails to run Swift unittests · Issue #56711 · apple/swift · GitHub and I'm not sure, but maybe https://github.com/apple/swift/pull/36971 will fix it ...

What do you mean by "here is a workaround just to build using Xcode"? Sounds like you came up with a solution. I don't understand how to make it work, I'm getting the same build fail error from Klass.swift and com.apple.xcode.tools.swift.compiler.

in the folder swift-project/swift you will find a CMakeLists.txt. Luciano's workaround consists in commenting out the line 1074 add_subdirectory(validation-test) in this file and then run the build command again. Worked for me!:)

1 Like

Thanks. I will try that, but after commenting that line out, should I do an Xcode command+B build, or the much slower terminal build with:

utils/build-script --verbose-build --skip-build-benchmarks \
  --skip-ios --skip-watchos --skip-tvos --swift-darwin-supported-archs "$(uname -m)" \--sccache --release-debuginfo --swift-disable-dead-stripping --test \
  --xcode --skip-test-cmark

Cmake will have to re-run, so I would recommend use build script =]

Thank you so much, your solution worked!
Now it's learning time for me, I have a lot of things to figure out from scratch before hopefully contributing to Swift.

So I think the right solution here is to not disable --validation-test. Rather I think that we probably want to just disable this test for now with the Xcode generator. The Xcode generator has many issues and isn't the normal build people use (we generally use ninja). So I am going to throw up a patch that does just that.

3 Likes

Its fixed. So you all should be good now.

1 Like

@Michael_Gottesman It seems like it introduced another problem

Xcode build is expecting to link against libswift.
I'm using ./swift/utils/build-script --xcode --release-debuginfo --debug-swift --skip-build-benchmarks --swift-darwin-supported-archs 'x86_64' --sccache --skip-ios --skip-tvos --skip-watchos --swift-disable-dead-stripping --skip-test-cmark ad Xcode 12.5 (12E262)

1 Like

@LucianoPAlmeida Did you end up finding a workaround for this? I'm hitting the same problem

@hborla At the time I just reverted the commit and continued with the previous workaround.
But now always build the dummy libswift with Xcode by QuietMisdreavus · Pull Request #38206 · apple/swift · GitHub have fixed this few days ago, so I think is just rebase with main =]

1 Like

Sorry if this is a stupid question, but how do you get the Xcode project file when you build with ninja? I looked through the build folder and didn't see anything with the .xcodeproj extension, and Xcode wouldn't open the folder directly (like it would a SwiftPM project).

In my understanding, if you build with ninja, you can't use Xcode and you will need another editor like VSCode.