Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

[SR-4974] Cannot build Android static lib on macOS #47551

Open
swift-ci opened this issue May 23, 2017 · 1 comment
Open

[SR-4974] Cannot build Android static lib on macOS #47551

swift-ci opened this issue May 23, 2017 · 1 comment
Labels
bug A deviation from expected or documented behavior. Also: expected but undesirable behavior. standard library Area: Standard library umbrella

Comments

@swift-ci
Copy link
Collaborator

Previous ID SR-4974
Radar None
Original Reporter jblatecky (JIRA User)
Type Bug

Attachment: Download

Environment

Swift master branch (LLVM 0af67ee12ff4f3fd8f9bdf4b879eebcce4825ec7, Clang 8ec8fa633cf4ada2e67fae7f888fe410bf7e0763, Swift 069ed3e)

Additional Detail from JIRA
Votes 0
Component/s Standard Library
Labels Bug
Assignee None
Priority Medium

md5: 0f65b3b0a7dfad4ccbb396e729badabd

relates to:

Issue Description:

Trying to build stdlib of Swift for Android on macOS is failing. If I understand the whole thing correctly, when I configure the build script to build for Android, it will do the following:

  • Building cmark-macosx-x86_64

  • Building llvm-macosx-x86_64

  • Building swift-macosx-x86_64 (with targets swift-test-stdlib-macosx-x86_64 swift-test-stdlib-android-armv7 swift-benchmark-macosx-x86_64) <– Failing here

Firstly, I don't understand why I have to build the macOS variant of the stdlib even if I ask specifically for the android one using the parameter `--stdlib-deployment-targets "android-armv7"`. Indeed, if I add this parameter, an error will be raised because CMake won't find swiftRuntime-macos target. Maybe this specific problem would need another ticket.

Secondly, the error that prevents me from building swift raises when the macOS variant is currently building. If I check the build commands, I think there is a problem because the Android sysroot and includes are appended to the macOS specifics commands, and not only on the Android ones.

If I refer to this PR (#4972), building static stdlib should be working. I've checked out the commit related to this PR and, even if I didn't succeed to build because of too recent dependencies, the build commands does not have this anomaly.

Here is the error raised when building with an up-to-date source:

/Users/jblatecky/dev/swift-source/swift/stdlib/public/stubs/LibcShims.cpp:103:1: error: static_assert failed "This platform's pthread_key_t differs. If you hit this assert, fix __swift_pthread_key_t's typedef in LibcShims.h by adding an #if guard and definition for your platform"
static_assert(std::is_same<__swift_pthread_key_t, pthread_key_t>::value,
^             ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

The command that raises this error:

[791/1257] /Users/jblatecky/dev/swift-source/build/Ninja-ReleaseAssert/llvm-macosx-x86_64/./bin/clang++   -DCMARK_STATIC_DEFINE -DGTEST_HAS_RTTI=0 -D_DEBUG -D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS -Istdlib/public/stubs -I/Users/jblatecky/dev/swift-source/swift/stdlib/public/stubs -Iinclude -I/Users/jblatecky/dev/swift-source/swift/include -I/Users/jblatecky/dev/swift-source/llvm/include -I/Users/jblatecky/dev/swift-source/build/Ninja-ReleaseAssert/llvm-macosx-x86_64/include -I/Users/jblatecky/dev/swift-source/build/Ninja-ReleaseAssert/llvm-macosx-x86_64/tools/clang/include -I/Users/jblatecky/dev/swift-source/llvm/tools/clang/include -I/Users/jblatecky/dev/swift-source/cmark/src -I/Users/jblatecky/dev/swift-source/build/Ninja-ReleaseAssert/cmark-macosx-x86_64/src -isystem /Users/jblatecky/dev/libiconv-libicu-android/armeabi-v7a/include -fno-stack-protector -stdlib=libc++ -fPIC -fvisibility-inlines-hidden -Wall -W -Wno-unused-parameter -Wwrite-strings -Wcast-qual -Wmissing-field-initializers -Wcovered-switch-default -Wnon-virtual-dtor -Wdelete-non-virtual-dtor -Wstring-conversion -Werror=date-time -std=c++11 -fcolor-diagnostics -Wdocumentation -Wimplicit-fallthrough -Wunreachable-code -Woverloaded-virtual -DOBJC_OLD_DISPATCH_PROTOTYPES=0 -fno-sanitize=all -DLLVM_DISABLE_ABI_BREAKING_CHECKS_ENFORCING=1 -O3  -isysroot /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.12.sdk   -UNDEBUG  -fno-exceptions -fno-rtti -Wglobal-constructors -Wexit-time-destructors -fvisibility=hidden -DswiftCore_EXPORTS -DSWIFT_RUNTIME_ENABLE_COW_EXISTENTIALS=1 -target armv7-none-linux-androideabi --sysroot=/Users/jblatecky/Library/Android/sdk/ndk-bundle/platforms/android-24/arch-arm --sysroot=/Users/jblatecky/Library/Android/sdk/ndk-bundle/platforms/android-24/arch-arm -B /Users/jblatecky/Library/Android/sdk/ndk-bundle/toolchains/arm-linux-androideabi-4.9/prebuilt/darwin-x86_64/arm-linux-androideabi/bin/ -O2 -g0 -UNDEBUG -I/Users/jblatecky/Library/Android/sdk/ndk-bundle/sources/cxx-stl/llvm-libc++/include -I/Users/jblatecky/Library/Android/sdk/ndk-bundle/sources/cxx-stl/llvm-libc++abi/include -I/Users/jblatecky/Library/Android/sdk/ndk-bundle/sources/android/support/include -DSWIFT_RUNTIME_ENABLE_COW_EXISTENTIALS=1 -MD -MT stdlib/public/stubs/CMakeFiles/swiftStdlibStubs-android-armv7.dir/LibcShims.cpp.o -MF stdlib/public/stubs/CMakeFiles/swiftStdlibStubs-android-armv7.dir/LibcShims.cpp.o.d -o stdlib/public/stubs/CMakeFiles/swiftStdlibStubs-android-armv7.dir/LibcShims.cpp.o -c /Users/jblatecky/dev/swift-source/swift/stdlib/public/stubs/LibcShims.cpp

Finally, for comparison, here is the command that we could find at the time of the PR (not on the same file, but at the same build step):

[108/1210] /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/clang++   -DCMARK_STATIC_DEFINE -DGTEST_HAS_RTTI=0 -D_DEBUG -D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS -Ilib/ClangImporter -I/Users/jblatecky/dev/swift-source/swift/lib/ClangImporter -Iinclude -I/Users/jblatecky/dev/swift-source/swift/include -I/Users/jblatecky/dev/swift-source/llvm/include -I/Users/jblatecky/dev/swift-source/build/Ninja-ReleaseAssert/llvm-macosx-x86_64/include -I/Users/jblatecky/dev/swift-source/build/Ninja-ReleaseAssert/llvm-macosx-x86_64/tools/clang/include -I/Users/jblatecky/dev/swift-source/llvm/tools/clang/include -I/Users/jblatecky/dev/swift-source/cmark/src -I/Users/jblatecky/dev/swift-source/build/Ninja-ReleaseAssert/cmark-macosx-x86_64/src -fno-stack-protector -stdlib=libc++ -fPIC -fvisibility-inlines-hidden -Wall -W -Wno-unused-parameter -Wwrite-strings -Wcast-qual -Wmissing-field-initializers -Wcovered-switch-default -Wnon-virtual-dtor -Wdelete-non-virtual-dtor -Wstring-conversion -Werror=date-time -std=c++11 -fcolor-diagnostics -Wdocumentation -Wimplicit-fallthrough -Wunreachable-code -Woverloaded-virtual -DOBJC_OLD_DISPATCH_PROTOTYPES=0 -O3  -isysroot /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.12.sdk   -UNDEBUG  -fno-exceptions -fno-rtti -DSWIFT_RUNTIME_ENABLE_COW_EXISTENTIALS=1 -target x86_64-apple-macosx10.9 -isysroot /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.12.sdk -arch x86_64 -F /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.12.sdk/../../../Developer/Library/Frameworks -mmacosx-version-min=10.9 -O2 -g0 -UNDEBUG -DSWIFT_RUNTIME_ENABLE_COW_EXISTENTIALS=1 -MD -MT lib/ClangImporter/CMakeFiles/swiftClangImporter.dir/ImportMacro.cpp.o -MF lib/ClangImporter/CMakeFiles/swiftClangImporter.dir/ImportMacro.cpp.o.d -o lib/ClangImporter/CMakeFiles/swiftClangImporter.dir/ImportMacro.cpp.o -c /Users/jblatecky/dev/swift-source/swift/lib/ClangImporter/ImportMacro.cpp
@belkadan
Copy link
Contributor

@modocache, is this supported?

@swift-ci swift-ci transferred this issue from apple/swift-issues Apr 25, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
bug A deviation from expected or documented behavior. Also: expected but undesirable behavior. standard library Area: Standard library umbrella
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
2 participants
@belkadan @swift-ci