You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository was archived by the owner on Aug 8, 2023. It is now read-only.
Repository navigation
This repository was archived by the owner on Aug 8, 2023. It is now read-only.
mbgl-test-runner fails to link in mapbox-gl-native-ios workspace #16259
The mapbox/mapbox-gl-native-ios repository’s make xproj command generates a macos.xcworkspace that includes various gl-native targets, including mbgl-test-runner. mbgl-test-runner fails to build with the following linker errors:
Showing All Messages
Ld /path/to/mapbox-gl-native-ios/build/macos/Debug/mbgl-test-runner normal x86_64 (in target 'mbgl-test-runner' from project 'Mapbox GL Native')
cd /path/to/mapbox-gl-native-ios/vendor/mapbox-gl-native
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/clang++ -target x86_64-apple-macos10.15 -isysroot /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.15.sdk -L/path/to/mapbox-gl-native-ios/build/macos/Debug -F/path/to/mapbox-gl-native-ios/build/macos/Debug -filelist /path/to/mapbox-gl-native-ios/build/macos/Mapbox\ GL\ Native.build/Debug/mbgl-test-runner.build/Objects-normal/x86_64/mbgl-test-runner.LinkFileList -Xlinker -object_path_lto -Xlinker /path/to/mapbox-gl-native-ios/build/macos/Mapbox\ GL\ Native.build/Debug/mbgl-test-runner.build/Objects-normal/x86_64/mbgl-test-runner_lto.o -Xlinker -no_deduplicate -Wl,-headerpad_max_install_names -Wl,-force_load /path/to/mapbox-gl-native-ios/build/macos/test/Debug/libmbgl-test.a /path/to/mapbox-gl-native-ios/build/macos/Debug/libmbgl-core.a /path/to/mapbox-gl-native-ios/build/macos/Debug/libmbgl-vendor-csscolorparser.a /path/to/mapbox-gl-native-ios/build/macos/Debug/libmbgl-vendor-parsedate.a /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.15.sdk/System/Library/Frameworks/OpenGL.framework/OpenGL.tbd -framework AppKit -framework CoreGraphics -framework CoreLocation -framework SystemConfiguration /path/to/mapbox-gl-native-ios/build/macos/Debug/libmbgl-vendor-icu.a -lsqlite3 -lz /path/to/mapbox-gl-native-ios/build/macos/test/Debug/libmbgl-vendor-googletest.a -Xlinker -dependency_info -Xlinker /path/to/mapbox-gl-native-ios/build/macos/Mapbox\ GL\ Native.build/Debug/mbgl-test-runner.build/Objects-normal/x86_64/mbgl-test-runner_dependency_info.dat -o /path/to/mapbox-gl-native-ios/build/macos/Debug/mbgl-test-runner
clang: error: no such file or directory: '/path/to/mapbox-gl-native-ios/build/macos/test/Debug/libmbgl-test.a'
clang: error: no such file or directory: '/path/to/mapbox-gl-native-ios/build/macos/test/Debug/libmbgl-vendor-googletest.a'
Command Ld failed with a nonzero exit code
This is the Debug configuration, but the same errors occur in the other configurations.
To work around this issue, I modified the mbgl-test-runner target’s OTHER_LDFLAGS build setting to remove test/ from the paths of libmbgl-test.a and libmbgl-vendor-googletest.a. The other paths are already correct. This is a trivial change inside Xcode, but it doesn’t persist because mbgl relies on CMake to generate Xcode projects on the fly. I’m not sure what CMake magic is required to fix these paths.
I think this issue would also affect any future iOS test runner that becomes buildable within Xcode. It’s very useful to be able to run these test runners as part of the overall map SDK workspace, so that we can more confidently make changes across repositories such as mapbox/mapbox-gl-native-ios#189 / #16253.
UnitTestAppTests also fails to link unless I unset FRAMEWORK_SEARCH_PATHS, which CMake hardcodes as /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/Library/Frameworks.
To reproduce, change this line to also pass in -DCMAKE_OSX_SYSROOT=iphoneos -DMBGL_IOS_UNIT_TEST=ON.
The tests don’t run on a device, probably due to this warning:
dyld: warning: could not load inserted library '/private/var/containers/Bundle/Application/12C5DCAD-DEDD-4D5C-B816-A63E4F213C21/UnitTestsApp.app/Frameworks/libXCTestBundleInject.dylib' into hardened process because image not found
I am not sure which one causes it, but I assume with above configuration, It reconfigured the build product path, which will cause the build lib relocating to mapbox-gl-native-ios/build/ios/Debug${EFFECTIVE_PLATFORM_NAME}/libmbgl-test.a
When Mapbox GL Native.xcodeproj is run inside another workspace, these paths need to be modified to point to the same build products directory that other workspace products are put into. It normally works, but I’m not sure what’s causing the test/ to persist in the paths for test targets.
It normally works, but I’m not sure what’s causing the test/ to persist in the paths for test targets.
This seems to be a limitation of CMake’s add_subdirectory command. CMake expects each subdirectory to represent a separate, self-contained executable target. This breaks Xcode’s expectation that the build products would commingle under a centralized build products folder.
The mbgl build system currently relies on SYMROOT to be set on each target, but inside a workspace, Xcode ignores the per-target SYMROOT in favor of a per-project SYMROOT or even a per-user setting: flutter/flutter#32494 (comment). It’ll put the build products somewhere else, causing the CMake-generated OTHER_LDFLAGS to become inaccurate.
Of all the antipatterns in how CMake configures Xcode, its reliance on an inaccurate SYMROOT isn’t especially severe, since there is a workaround: I can manually fix up the build settings every time I rerun CMake or perhaps override the paths using an .xcconfig file.
The tests don’t run on a device, probably due to this warning:
dyld: warning: could not load inserted library '/private/var/containers/Bundle/Application/12C5DCAD-DEDD-4D5C-B816-A63E4F213C21/UnitTestsApp.app/Frameworks/libXCTestBundleInject.dylib' into hardened process because image not found
Might be related to this build-time warning:
warning: skipping copy phase strip, binary is code signed: /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/usr/lib/libXCTestBundleInject.dylib
Activity
1ec5 commentedon Mar 5, 2020
UnitTestAppTests also fails to link unless I unset
FRAMEWORK_SEARCH_PATHS, which CMake hardcodes as/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/Library/Frameworks.To reproduce, change this line to also pass in
-DCMAKE_OSX_SYSROOT=iphoneos -DMBGL_IOS_UNIT_TEST=ON.The tests don’t run on a device, probably due to this warning:
zmiao commentedon Mar 19, 2020
I think it is not an issue related to gl-native.
If I run from mapbox-gl-native-ios project with the following script:
Then try to build the TestAPP with Xcode, there were no linking errors. As by default the linker flag is configured to linking to
and the actual build products will be inside
test/Debug${EFFECTIVE_PLATFORM_NAME}/However, if I run
make iproj, which will copy theWorkspaceSettings.xcsettings, I checked inside<key>CustomBuildIntermediatesPath</key><string>../../build/ios</string><key>CustomBuildLocationType</key><string>RelativeToWorkspace</string><key>CustomBuildProductsPath</key><string>../../build/ios</string><key>DerivedDataCustomLocation</key><string>../../build/ios</string>I am not sure which one causes it, but I assume with above configuration, It reconfigured the build product path, which will cause the build lib relocating to
mapbox-gl-native-ios/build/ios/Debug${EFFECTIVE_PLATFORM_NAME}/libmbgl-test.a1ec5 commentedon Mar 23, 2020
When Mapbox GL Native.xcodeproj is run inside another workspace, these paths need to be modified to point to the same build products directory that other workspace products are put into. It normally works, but I’m not sure what’s causing the test/ to persist in the paths for test targets.
1ec5 commentedon Apr 23, 2020
This seems to be a limitation of CMake’s
add_subdirectorycommand. CMake expects each subdirectory to represent a separate, self-contained executable target. This breaks Xcode’s expectation that the build products would commingle under a centralized build products folder.mapbox-gl-native/CMakeLists.txt
Lines 1040 to 1042 in 1798bda
The mbgl build system currently relies on
SYMROOTto be set on each target, but inside a workspace, Xcode ignores the per-targetSYMROOTin favor of a per-projectSYMROOTor even a per-user setting: flutter/flutter#32494 (comment). It’ll put the build products somewhere else, causing the CMake-generatedOTHER_LDFLAGSto become inaccurate.Of all the antipatterns in how CMake configures Xcode, its reliance on an inaccurate
SYMROOTisn’t especially severe, since there is a workaround: I can manually fix up the build settings every time I rerun CMake or perhaps override the paths using an .xcconfig file.1ec5 commentedon Apr 23, 2020
Might be related to this build-time warning:
tmpsantos commentedon Apr 24, 2020
@1ec5 I think setting
CMAKE_RUNTIME_OUTPUT_DIRECTORYtoCMAKE_BINARY_DIRwill solve the problemtmpsantos commentedon Apr 24, 2020
Making a PR here for you to test
tmpsantos commentedon Apr 24, 2020
Can you give this a try?
#16431
1ec5 commentedon Oct 27, 2020
/cc @ChrisLoer