Xcodebuild can not resolve package dependencies using build-wrapper-macosx-x86

Get help SonarCloud
, ,
#1

Hi, I have an issue with the build-wrapper command:
Our codebase contains Swift & Obj-C code and we use Xcode 12.
build-wrapper version: 6.13 (macosx-x86)

When running the build wrapper command

build-wrapper-macosx-x86 --out-dir sonar-reports xcodebuild -workspace MyProject.xcworkspace -scheme MyProject-Alpha -derivedDataPath derived_data_path build CODE_SIGNING_REQUIRED=NO

we get following error:

...

xcodebuild: error: Could not resolve package dependencies:
  build-wrapper: connect to /tmp/build-wrapper-socket.27NmvM: Operation not permitted
  build-wrapper: connect to /tmp/build-wrapper-socket.27NmvM: Operation not permitted
  build-wrapper: connect to /tmp/build-wrapper-socket.27NmvM: Operation not permitted
  build-wrapper: connect to /tmp/build-wrapper-socket.27NmvM: Operation not permitted
  ...

I think the error is related to Xcode resolving Swift packages. When I run the same xcodebuild command without the build-wrapper package resolution works fine.

The build-wrapper.log ends with these lines:

...
Thu Oct 15 09:56:37 2020: finalizing json file
Thu Oct 15 09:56:37 2020: returned with code: 74

I couldn’t find any information on the returned code.

#2

Hi @heinzl,

you are using an old version of the build-wrapper and perhaps of the cfamily analyzer. Could you please upgrade to the latest version and try again?

#3

I’m sorry I posted the wrong version I’m using 6.13 (macosx-x86)

#4

Hi @heinzl,

what version of macOS are you on? What if you try with a small hello world project?

#5

Hi @mpaladin,

I’m on macOS 10.15.5. I will try a small hello world project with one Swift Package dependency.

#6

Hi @mpaladin, I created a Hello World project (Swift + Obj-C) with only one public Swift Package dependency.
When I run xcodebuild without the build-wrapper Swift Package dependencies are resolved and fetched without an error.

xcodebuild -project BuildWrapperTest.xcodeproj -scheme BuildWrapperTest -derivedDataPath derived_data clean build CODE_SIGNING_REQUIRED=NO

If I run the same command using the build wrapper it fails with the same error I mentioned in my post.

../command-line-tools/sonar-obj-c-build-wrapper/build-wrapper-macosx-x86 --out-dir sonar-reports-test xcodebuild -project BuildWrapperTest.xcodeproj -scheme BuildWrapperTest -derivedDataPath derived_data clean build CODE_SIGNING_REQUIRED=NO
#7

Hi @heinzl,

thank you for your answer. Could you please share this hello world project so I can have a look at it on my side?

#8

@mpaladin Sure! here is the project:
BuildWrapperTest.zip (34.9 KB)

#9

@mpaladin I haven’t mentioned yet that the issue occurs when running it on CI. (CircleCI)

#10

Hi @heinzl,

thank you, I am going to have a look.

Are you getting the same locally?

#11

No, it works locally. We had previously issues with Xcode resolving Swift Packages but it is working now, expect if we use the build-wrapper so there has to be something we have to configure differently when using the build-wrapper. FYI: It worked with the build-wrapper while we used Xcode 11

#12

@mpaladin Thank you for having a look, much appreciated! Let me know if you need any additional information.

#13

Hi @heinzl,

thank you, but if you say that it works locally I don’t see how I can reproduce it.

#14

Yes, but something has to be different when using the buil-wrapper. Maybe you can help me with the error code. How can I get more information on the error code? Is it a error from the build-wrapper or does the build wrapper forward error codes from xcode?

#15

Hi @heinzl ,

the build-wrapper forward error codes of the processes.

For your information I tried the project you provided and it works both locally and on Azure DevOps without any issue. On both tests I used macOS 10.15 and Xcode 12.

#16

Thanks for giving it a try

#17

Hi @heinzl,

I wonder whether in CircleCI there is something which may interfer with build-wrapper and the build. Could you check if the environment contain a variable named DYLD_INSERT_LIBRARIES before launching the build-wrapper?

#18

Thanks I will check that, but in the mean time I found a similar issue https://github.com/samuelmeuli/tmignore/issues/9 I think the cause of the issue could be the same as I experience. It looks like it is a permission/sandboxing issue when running Xcode build from a subprocess or something similar.

A successful run looks like this:

Resolve Package Graph

Fetching https://github.com/ReactiveX/RxSwift.git

Cloning https://github.com/ReactiveX/RxSwift.git

Checking out https://github.com/ReactiveX/RxSwift.git at 6.0.0-rc.1


Resolved source packages:
  RxSwift: https://github.com/ReactiveX/RxSwift.git @ 6.0.0-rc.1

A failed run like this:

Resolve Package Graph

Fetching https://github.com/ReactiveX/RxSwift.git

xcodebuild: error: Could not resolve package dependencies:
  build-wrapper: connect to /tmp/build-wrapper-socket.YiKkHY: Operation not permitted

The fetching takes also a while to complete so my hypothesis is that fetching works but it fails at the cloning step when writing to disk and it fails to access the directory or something.

#19

Could you check if the environment contain a variable named DYLD_INSERT_LIBRARIES before launching the build-wrapper?

No there is no variable like this before launching.

#20

@mpaladin Hello, I saw that a similar issue was solved by removing the com.apple.quarantine attribute.

I tried to remove the attribute from the build-wrapper but no success…

xattr -d com.apple.quarantine ../command-line-tools/sonar-obj-c-build-wrapper/build-wrapper-macosx-x86

xattr: ../command-line-tools/sonar-obj-c-build-wrapper/build-wrapper-macosx-x86: No such xattr: com.apple.quarantine

Do you think this can help us in anyway, maybe we have to disable sandboxing somewhere else?