128de1949f
Write an `ndk.dir` property with the directory path to `android/source/local.properties` instead, similar to how it's done for `sdk.dir`. Also, rename the `ANDROID_NDK_HOME` variable that's assigned in configure.ac that holds the corresponding value to `ANDROID_NDK_DIR`, because the gradle warning still shows up if that environment variable is set in addition to having an `ndk.dir` property in `local.properties`. This makes the following gradle warning disappear: > > Task :stripStrippedUIDebugDebugSymbols > WARNING: Support for ANDROID_NDK_HOME is deprecated and will be removed in the future. Use android.ndkVersion in build.gradle instead. > Support for ANDROID_NDK_HOME is deprecated and will be removed in the future. Use android.ndkVersion in build.gradle instead. Note however, that with this approach of using the `ndk.dir` property instead of the suggested `android.ndkVersion` (with the latter having the stricter requirement that the `ndk` dir would have to be a subdir of the SDK dir), doing the actual upgrade to a newer Gradle (plugin) version in follow-up commit Change-Id Ia982d72d877e229c3006c6d528b830d16c88481f "android: Update Android Gradle Plugin to 7.1.3" revealed that the use of the `ndk.dir` property is deprecated in newer Gradle (plugin) versions as well, resulting in this warning. > > Task :stripStrippedUIDebugDebugSymbols > [CXX5106] NDK was located by using ndk.dir property. This method is > deprecated and will be removed in a future release. Please delete > ndk.dir from local.properties and set android.ndkVersion to > [20.0.5594570] in all native modules in the project. > https://developer.android.com/r/studio-ui/ndk-dir It might make sense to address that in a follow-up step, but for now, it's an improvement and keeps it working after the upgrade without potentially causing any incompatibility problems with existing autogen configurations, while support for the `ANDROID_NDK_HOME` env var that was used so far seems to have been dropped, resulting in > > Task :stripStrippedUIDebugDebugSymbols > Unable to strip the following libraries, packaging them as they are: > libc++_shared.so, libfreebl3.so, liblo-native-code.so, libnspr4.so, > libnss3.so, libnssckbi.so, libnssdbm3.so, libnssutil3.so, > libplc4.so, libplds4.so, libsmime3.so, libsoftokn3.so, > libsqlite3.so, libssl3.so. instead if upgrading gradle without switching to the use of the property. Change-Id: I4a090e8736dac80777f69b0e12819b9c056f582b Reviewed-on: https://gerrit.libreoffice.org/c/core/+/133177 Tested-by: Jenkins Reviewed-by: Michael Weghorn <m.weghorn@posteo.de> |
||
|---|---|---|
| .. | ||
| asan.patch.1 | ||
| clang-cl.patch.0 | ||
| ExternalPackage_nss.mk | ||
| ExternalProject_nss.mk | ||
| macos-dlopen.patch.0 | ||
| Makefile | ||
| Module_nss.mk | ||
| nsinstall.py | ||
| nss-3.13.5-zlib-werror.patch | ||
| nss-android.patch.1 | ||
| nss-bz1646594.patch.1 | ||
| nss-ios.patch | ||
| nss-restore-manual-pre-dependencies.patch.1 | ||
| nss-win32-make.patch.1 | ||
| nss.aix.patch | ||
| nss.bzmozilla1238154.patch | ||
| nss.cygwin64.in32bit.patch | ||
| nss.nowerror.patch | ||
| nss.patch | ||
| nss.utf8bom.patch.1 | ||
| nss.vs2015.patch | ||
| nss.vs2015.pdb.patch | ||
| nss.windows.patch | ||
| nss_macosx.patch | ||
| README | ||
| ubsan.patch.0 | ||
| UnpackedTarball_nss.mk | ||
Contains the Network Security Services (NSS) libraries from Mozilla == Fips 140 and signed libraries == Fips 140 mode is not supported. That is, the *.chk files containing the checksums for the cryptographic module are not delivered into instdir and will not be part of the OOo installation sets. Signing has been turned off because - we change the rpath (install names) after signing which breaks the signatures (Mac) - sqlite conflicts with the system sqlite when signing which breaks the build See also [https://developer.mozilla.org/en-US/docs/Mozilla/Projects/NSS/NSS_Tech_Notes/nss_tech_note6] == libsqlite3 == With all supported macOS SDK we use NSS_USE_SYSTEM_SQLITE=1 to build using the system sqlite. == system NSS on Linux == Note that different Linux distributions use different SONAMEs for the NSS libraries, so it is not possible to use --with-system-nss and build a portable generic LO installation set, despite NSS upstream apparently maintaining ABI compatibility. Debian Squeeze: 0x000000000000000e (SONAME) Library soname: [libnss3.so.1d] Fedora 20: 0x000000000000000e (SONAME) Library soname: [libnss3.so] For the record, the LSB specified SONAME is libnss3.so http://refspecs.linuxfoundation.org/LSB_4.1.0/LSB-Core-generic/LSB-Core-generic/libnss3.html