Creation of libxamarin-app.so fails on macOS Catalina due to usage of 32bit link tool
#3564
Assignees
Labels
Area: App+Library Build
Issues when building Library projects or Application projects.
vs-sync
For internal use only; creates a VSTS "mirror" issue.
Milestone
Comments
pjcollins
added a commit
that referenced
this issue
Aug 30, 2019
Fixes: #3564 Adds an overridable `$(AndroidBinUtilsDirectory)` property which is used to specify the directory that contains `as`, `ld`, and `strip` tools. The default value for this property is the installation path of our distribution of these tools, `$(MonoAndroidBinDirectory)\ndk\`.
grendello
added
Area: App+Library Build
jonpryor
pushed a commit
that referenced
this issue
Sep 4, 2019
Fixes: #3564 Install Visual Studio for Mac on macOS 10.15 Catalina Beta 7, and build a project. Expected results: it builds! Actual results: not so much: Task Parameter:AndroidSdkBuildToolsPath=…/android-sdk-macosx/build-tools/28.0.3/ (TaskId:273) [Native Linker] …/android-sdk-macosx/build-tools/28.0.3/aarch64-linux-android-ld --unresolved-symbols=ignore-in-shared-libs --export-dynamic -soname libxamarin-app.so -z relro -z noexecstack --enable-new-dtags --eh-frame-hdr -shared --build-id --warn-shared-textrel --fatal-warnings -o obj/Release/app_shared_libraries/arm64-v8a/libxamarin-app.so --fix-cortex-a53-843419 -m aarch64linux obj/Release/android/typemap.jm.arm64-v8a.o obj/Release/android/typemap.mj.arm64-v8a.o obj/Release/android/environment.arm64-v8a.o (TaskId:273) [Native Linker] …/android-sdk-macosx/build-tools/28.0.3/arm-linux-androideabi-ld --unresolved-symbols=ignore-in-shared-libs --export-dynamic -soname libxamarin-app.so -z relro -z noexecstack --enable-new-dtags --eh-frame-hdr -shared --build-id --warn-shared-textrel --fatal-warnings -o obj/Release/app_shared_libraries/armeabi-v7a/libxamarin-app.so -X -m armelf_linux_eabi obj/Release/android/typemap.jm.armeabi-v7a.o obj/Release/android/typemap.mj.armeabi-v7a.o obj/Release/android/environment.armeabi-v7a.o (TaskId:273) /Library/Frameworks/Mono.framework/External/xbuild/Xamarin/Android/Xamarin.Android.Common.targets(2869,3): error XA3001: Could not link native shared library: libxamarin-app.so Done executing task "LinkApplicationSharedLibraries" -- FAILED. The cause of the error is: 1. `libxamarin-app.so` is required (see decfbcc), which 2. Requires that we be able to execute `arm-linux-androideabi-ld`, and 3. macOS 10.15 Catalina no longer executes 32-bit binaries. As it happens™, the Android SDK Build-tools package still contains 32-bit native binaries, up through and including Build-tools 29.0.0. (The Android NDK *does* contain 64-bit binaries.) At this time, we don't know if there will *be* a Build-tools package which contains 64-bit binaries before Catalina drops. It is also moot: as of f0b1e8a we now redistribute *our own* `*-ld` and `*-strip` utilities, which are 64-bit. There is thus no need to use the Build-tools versions of these files. The problem here was that some of our tasks used the bundled NDK tools, while some of our tasks didn't, and instead required that they exist within `$(AndroidSdkBuildToolsPath)`, the Android SDK Build-tools directory. Add a new overridable `$(AndroidBinUtilsDirectory)` MSBuild property which contains the `*-as`, `*-ld`, and `*-strip` utilities needed for assembling and linking native code. The value of this new property defaults to inside the Xamarin.Android installation path, `$(MonoAndroidBinDirectory)\ndk\`. `$(AndroidBinUtilsDirectory)` is an overridable property because the NDK utilities are GPL'd, and if someone wishes to use their own version of these utilities, overriding `$(AndroidBinUtilsDirectory)` will be much easier than replacing files within the installation directory. The result is that builds now use reliably 64-bit binaries: Task "LinkApplicationSharedLibraries" [Native Linker] /Library/Frameworks/Xamarin.Android.framework/Libraries/xbuild/Xamarin/Android/Darwin/ndk/aarch64-linux-android-ld --unresolved-symbols=ignore-in-shared-libs --export-dynamic -soname libxamarin-app.so -z relro -z noexecstack --enable-new-dtags --eh-frame-hdr -shared --build-id --warn-shared-textrel --fatal-warnings -o obj/Release/app_shared_libraries/arm64-v8a/libxamarin-app.so --fix-cortex-a53-843419 -m aarch64linux obj/Release/android/typemap.jm.arm64-v8a.o obj/Release/android/typemap.mj.arm64-v8a.o obj/Release/android/environment.arm64-v8a.o [Native Linker] /Library/Frameworks/Xamarin.Android.framework/Libraries/xbuild/Xamarin/Android/Darwin/ndk/arm-linux-androideabi-ld --unresolved-symbols=ignore-in-shared-libs --export-dynamic -soname libxamarin-app.so -z relro -z noexecstack --enable-new-dtags --eh-frame-hdr -shared --build-id --warn-shared-textrel --fatal-warnings -o obj/Release/app_shared_libraries/armeabi-v7a/libxamarin-app.so -X -m armelf_linux_eabi obj/Release/android/typemap.jm.armeabi-v7a.o obj/Release/android/typemap.mj.armeabi-v7a.o obj/Release/android/environment.armeabi-v7a.o Done executing task "LinkApplicationSharedLibraries".
jonpryor
pushed a commit
that referenced
this issue
Sep 4, 2019
Fixes: #3564 Install Visual Studio for Mac on macOS 10.15 Catalina Beta 7, and build a project. Expected results: it builds! Actual results: not so much: Task Parameter:AndroidSdkBuildToolsPath=…/android-sdk-macosx/build-tools/28.0.3/ (TaskId:273) [Native Linker] …/android-sdk-macosx/build-tools/28.0.3/aarch64-linux-android-ld --unresolved-symbols=ignore-in-shared-libs --export-dynamic -soname libxamarin-app.so -z relro -z noexecstack --enable-new-dtags --eh-frame-hdr -shared --build-id --warn-shared-textrel --fatal-warnings -o obj/Release/app_shared_libraries/arm64-v8a/libxamarin-app.so --fix-cortex-a53-843419 -m aarch64linux obj/Release/android/typemap.jm.arm64-v8a.o obj/Release/android/typemap.mj.arm64-v8a.o obj/Release/android/environment.arm64-v8a.o (TaskId:273) [Native Linker] …/android-sdk-macosx/build-tools/28.0.3/arm-linux-androideabi-ld --unresolved-symbols=ignore-in-shared-libs --export-dynamic -soname libxamarin-app.so -z relro -z noexecstack --enable-new-dtags --eh-frame-hdr -shared --build-id --warn-shared-textrel --fatal-warnings -o obj/Release/app_shared_libraries/armeabi-v7a/libxamarin-app.so -X -m armelf_linux_eabi obj/Release/android/typemap.jm.armeabi-v7a.o obj/Release/android/typemap.mj.armeabi-v7a.o obj/Release/android/environment.armeabi-v7a.o (TaskId:273) /Library/Frameworks/Mono.framework/External/xbuild/Xamarin/Android/Xamarin.Android.Common.targets(2869,3): error XA3001: Could not link native shared library: libxamarin-app.so Done executing task "LinkApplicationSharedLibraries" -- FAILED. The cause of the error is: 1. `libxamarin-app.so` is required (see decfbcc), which 2. Requires that we be able to execute `arm-linux-androideabi-ld`, and 3. macOS 10.15 Catalina no longer executes 32-bit binaries. As it happens™, the Android SDK Build-tools package still contains 32-bit native binaries, up through and including Build-tools 29.0.0. (The Android NDK *does* contain 64-bit binaries.) At this time, we don't know if there will *be* a Build-tools package which contains 64-bit binaries before Catalina drops. It is also moot: as of f0b1e8a we now redistribute *our own* `*-ld` and `*-strip` utilities, which are 64-bit. There is thus no need to use the Build-tools versions of these files. The problem here was that some of our tasks used the bundled NDK tools, while some of our tasks didn't, and instead required that they exist within `$(AndroidSdkBuildToolsPath)`, the Android SDK Build-tools directory. Add a new overridable `$(AndroidBinUtilsDirectory)` MSBuild property which contains the `*-as`, `*-ld`, and `*-strip` utilities needed for assembling and linking native code. The value of this new property defaults to inside the Xamarin.Android installation path, `$(MonoAndroidBinDirectory)\ndk\`. `$(AndroidBinUtilsDirectory)` is an overridable property because the NDK utilities are GPL'd, and if someone wishes to use their own version of these utilities, overriding `$(AndroidBinUtilsDirectory)` will be much easier than replacing files within the installation directory. The result is that builds now use reliably 64-bit binaries: Task "LinkApplicationSharedLibraries" [Native Linker] /Library/Frameworks/Xamarin.Android.framework/Libraries/xbuild/Xamarin/Android/Darwin/ndk/aarch64-linux-android-ld --unresolved-symbols=ignore-in-shared-libs --export-dynamic -soname libxamarin-app.so -z relro -z noexecstack --enable-new-dtags --eh-frame-hdr -shared --build-id --warn-shared-textrel --fatal-warnings -o obj/Release/app_shared_libraries/arm64-v8a/libxamarin-app.so --fix-cortex-a53-843419 -m aarch64linux obj/Release/android/typemap.jm.arm64-v8a.o obj/Release/android/typemap.mj.arm64-v8a.o obj/Release/android/environment.arm64-v8a.o [Native Linker] /Library/Frameworks/Xamarin.Android.framework/Libraries/xbuild/Xamarin/Android/Darwin/ndk/arm-linux-androideabi-ld --unresolved-symbols=ignore-in-shared-libs --export-dynamic -soname libxamarin-app.so -z relro -z noexecstack --enable-new-dtags --eh-frame-hdr -shared --build-id --warn-shared-textrel --fatal-warnings -o obj/Release/app_shared_libraries/armeabi-v7a/libxamarin-app.so -X -m armelf_linux_eabi obj/Release/android/typemap.jm.armeabi-v7a.o obj/Release/android/typemap.mj.armeabi-v7a.o obj/Release/android/environment.armeabi-v7a.o Done executing task "LinkApplicationSharedLibraries".
jonpryor
pushed a commit
that referenced
this issue
Sep 4, 2019
Fixes: #3564 Install Visual Studio for Mac on macOS 10.15 Catalina Beta 7, and build a project. Expected results: it builds! Actual results: not so much: Task Parameter:AndroidSdkBuildToolsPath=…/android-sdk-macosx/build-tools/28.0.3/ (TaskId:273) [Native Linker] …/android-sdk-macosx/build-tools/28.0.3/aarch64-linux-android-ld --unresolved-symbols=ignore-in-shared-libs --export-dynamic -soname libxamarin-app.so -z relro -z noexecstack --enable-new-dtags --eh-frame-hdr -shared --build-id --warn-shared-textrel --fatal-warnings -o obj/Release/app_shared_libraries/arm64-v8a/libxamarin-app.so --fix-cortex-a53-843419 -m aarch64linux obj/Release/android/typemap.jm.arm64-v8a.o obj/Release/android/typemap.mj.arm64-v8a.o obj/Release/android/environment.arm64-v8a.o (TaskId:273) [Native Linker] …/android-sdk-macosx/build-tools/28.0.3/arm-linux-androideabi-ld --unresolved-symbols=ignore-in-shared-libs --export-dynamic -soname libxamarin-app.so -z relro -z noexecstack --enable-new-dtags --eh-frame-hdr -shared --build-id --warn-shared-textrel --fatal-warnings -o obj/Release/app_shared_libraries/armeabi-v7a/libxamarin-app.so -X -m armelf_linux_eabi obj/Release/android/typemap.jm.armeabi-v7a.o obj/Release/android/typemap.mj.armeabi-v7a.o obj/Release/android/environment.armeabi-v7a.o (TaskId:273) /Library/Frameworks/Mono.framework/External/xbuild/Xamarin/Android/Xamarin.Android.Common.targets(2869,3): error XA3001: Could not link native shared library: libxamarin-app.so Done executing task "LinkApplicationSharedLibraries" -- FAILED. The cause of the error is: 1. `libxamarin-app.so` is required (see decfbcc), which 2. Requires that we be able to execute `arm-linux-androideabi-ld`, and 3. macOS 10.15 Catalina no longer executes 32-bit binaries. As it happens™, the Android SDK Build-tools package still contains 32-bit native binaries, up through and including Build-tools 29.0.0. (The Android NDK *does* contain 64-bit binaries.) At this time, we don't know if there will *be* a Build-tools package which contains 64-bit binaries before Catalina drops. It is also moot: as of f0b1e8a we now redistribute *our own* `*-ld` and `*-strip` utilities, which are 64-bit. There is thus no need to use the Build-tools versions of these files. The problem here was that some of our tasks used the bundled NDK tools, while some of our tasks didn't, and instead required that they exist within `$(AndroidSdkBuildToolsPath)`, the Android SDK Build-tools directory. Add a new overridable `$(AndroidBinUtilsDirectory)` MSBuild property which contains the `*-as`, `*-ld`, and `*-strip` utilities needed for assembling and linking native code. The value of this new property defaults to inside the Xamarin.Android installation path, `$(MonoAndroidBinDirectory)\ndk\`. `$(AndroidBinUtilsDirectory)` is an overridable property because the NDK utilities are GPL'd, and if someone wishes to use their own version of these utilities, overriding `$(AndroidBinUtilsDirectory)` will be much easier than replacing files within the installation directory. The result is that builds now use reliably 64-bit binaries: Task "LinkApplicationSharedLibraries" [Native Linker] /Library/Frameworks/Xamarin.Android.framework/Libraries/xbuild/Xamarin/Android/Darwin/ndk/aarch64-linux-android-ld --unresolved-symbols=ignore-in-shared-libs --export-dynamic -soname libxamarin-app.so -z relro -z noexecstack --enable-new-dtags --eh-frame-hdr -shared --build-id --warn-shared-textrel --fatal-warnings -o obj/Release/app_shared_libraries/arm64-v8a/libxamarin-app.so --fix-cortex-a53-843419 -m aarch64linux obj/Release/android/typemap.jm.arm64-v8a.o obj/Release/android/typemap.mj.arm64-v8a.o obj/Release/android/environment.arm64-v8a.o [Native Linker] /Library/Frameworks/Xamarin.Android.framework/Libraries/xbuild/Xamarin/Android/Darwin/ndk/arm-linux-androideabi-ld --unresolved-symbols=ignore-in-shared-libs --export-dynamic -soname libxamarin-app.so -z relro -z noexecstack --enable-new-dtags --eh-frame-hdr -shared --build-id --warn-shared-textrel --fatal-warnings -o obj/Release/app_shared_libraries/armeabi-v7a/libxamarin-app.so -X -m armelf_linux_eabi obj/Release/android/typemap.jm.armeabi-v7a.o obj/Release/android/typemap.mj.armeabi-v7a.o obj/Release/android/environment.armeabi-v7a.o Done executing task "LinkApplicationSharedLibraries".
jonpryor
pushed a commit
to jonpryor/xamarin-android
that referenced
this issue
Sep 4, 2019
Fixes: dotnet#3564 Install Visual Studio for Mac on macOS 10.15 Catalina Beta 7, and build a project. Expected results: it builds! Actual results: not so much: Task Parameter:AndroidSdkBuildToolsPath=…/android-sdk-macosx/build-tools/28.0.3/ (TaskId:273) [Native Linker] …/android-sdk-macosx/build-tools/28.0.3/aarch64-linux-android-ld --unresolved-symbols=ignore-in-shared-libs --export-dynamic -soname libxamarin-app.so -z relro -z noexecstack --enable-new-dtags --eh-frame-hdr -shared --build-id --warn-shared-textrel --fatal-warnings -o obj/Release/app_shared_libraries/arm64-v8a/libxamarin-app.so --fix-cortex-a53-843419 -m aarch64linux obj/Release/android/typemap.jm.arm64-v8a.o obj/Release/android/typemap.mj.arm64-v8a.o obj/Release/android/environment.arm64-v8a.o (TaskId:273) [Native Linker] …/android-sdk-macosx/build-tools/28.0.3/arm-linux-androideabi-ld --unresolved-symbols=ignore-in-shared-libs --export-dynamic -soname libxamarin-app.so -z relro -z noexecstack --enable-new-dtags --eh-frame-hdr -shared --build-id --warn-shared-textrel --fatal-warnings -o obj/Release/app_shared_libraries/armeabi-v7a/libxamarin-app.so -X -m armelf_linux_eabi obj/Release/android/typemap.jm.armeabi-v7a.o obj/Release/android/typemap.mj.armeabi-v7a.o obj/Release/android/environment.armeabi-v7a.o (TaskId:273) /Library/Frameworks/Mono.framework/External/xbuild/Xamarin/Android/Xamarin.Android.Common.targets(2869,3): error XA3001: Could not link native shared library: libxamarin-app.so Done executing task "LinkApplicationSharedLibraries" -- FAILED. The cause of the error is: 1. `libxamarin-app.so` is required (see decfbcc), which 2. Requires that we be able to execute `arm-linux-androideabi-ld`, and 3. macOS 10.15 Catalina no longer executes 32-bit binaries. As it happens™, the Android SDK Build-tools package still contains 32-bit native binaries, up through and including Build-tools 29.0.0. (The Android NDK *does* contain 64-bit binaries.) At this time, we don't know if there will *be* a Build-tools package which contains 64-bit binaries before Catalina drops. It is also moot: as of f0b1e8a we now redistribute *our own* `*-ld` and `*-strip` utilities, which are 64-bit. There is thus no need to use the Build-tools versions of these files. The problem here was that some of our tasks used the bundled NDK tools, while some of our tasks didn't, and instead required that they exist within `$(AndroidSdkBuildToolsPath)`, the Android SDK Build-tools directory. Add a new overridable `$(AndroidBinUtilsDirectory)` MSBuild property which contains the `*-as`, `*-ld`, and `*-strip` utilities needed for assembling and linking native code. The value of this new property defaults to inside the Xamarin.Android installation path, `$(MonoAndroidBinDirectory)\ndk\`. `$(AndroidBinUtilsDirectory)` is an overridable property because the NDK utilities are GPL'd, and if someone wishes to use their own version of these utilities, overriding `$(AndroidBinUtilsDirectory)` will be much easier than replacing files within the installation directory. The result is that builds now use reliably 64-bit binaries: Task "LinkApplicationSharedLibraries" [Native Linker] /Library/Frameworks/Xamarin.Android.framework/Libraries/xbuild/Xamarin/Android/Darwin/ndk/aarch64-linux-android-ld --unresolved-symbols=ignore-in-shared-libs --export-dynamic -soname libxamarin-app.so -z relro -z noexecstack --enable-new-dtags --eh-frame-hdr -shared --build-id --warn-shared-textrel --fatal-warnings -o obj/Release/app_shared_libraries/arm64-v8a/libxamarin-app.so --fix-cortex-a53-843419 -m aarch64linux obj/Release/android/typemap.jm.arm64-v8a.o obj/Release/android/typemap.mj.arm64-v8a.o obj/Release/android/environment.arm64-v8a.o [Native Linker] /Library/Frameworks/Xamarin.Android.framework/Libraries/xbuild/Xamarin/Android/Darwin/ndk/arm-linux-androideabi-ld --unresolved-symbols=ignore-in-shared-libs --export-dynamic -soname libxamarin-app.so -z relro -z noexecstack --enable-new-dtags --eh-frame-hdr -shared --build-id --warn-shared-textrel --fatal-warnings -o obj/Release/app_shared_libraries/armeabi-v7a/libxamarin-app.so -X -m armelf_linux_eabi obj/Release/android/typemap.jm.armeabi-v7a.o obj/Release/android/typemap.mj.armeabi-v7a.o obj/Release/android/environment.armeabi-v7a.o Done executing task "LinkApplicationSharedLibraries".
|
A new Preview version has now been published that includes a fix for this item. The fix is not yet included in a Release version. I will update this item again when a Release version is available that includes the fix. Fix included in Xamarin.Android 10.0.0.43. Fix included on macOS in Visual Studio 2019 for Mac version 8.3 Preview 5. To try the Preview version that includes the fix, check for the latest updates on the Preview updater channel. (The fix is not relevant for Windows.) |
|
Release status update A new Release version has now been published that includes the fix for this item. Fix included in Xamarin.Android 10.0.0.43 Fix included on macOS in Visual Studio 2019 for Mac version 8.3. To get the new version that includes the fix, check for the latest updates on the Stable updater channel. (The fix is not relevant for Windows.) |
|
@brendanzagaeski Still issue occurs after upgrading.. my Mac VS version is 8.4 and XA is 10.2.0 |
|
@xhashimks, thanks for the info! When you get a chance, if you could submit a new issue with additional details about your scenario, including the diagnostic build output or possibly an example project, so that the team can take a look, that would be perfect. Thanks in advance! |
ghost
locked as resolved and limited conversation to collaborators
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Steps to Reproduce
Expected Behavior
On Catalina, we'll need to ensure our build processes use the link/strip tools that we are re-distributing, rather than the ones from
$(AndroidSDK)/build-tools/*.Actual Behavior
Version Information
d16-3 and master
Log File
http://xqa.blob.core.windows.net/gist/log-6288f3af2576434780150fb813d5907b.txt
The text was updated successfully, but these errors were encountered: