forked from amazingfate/loongoffice
489414f239
It's not obvious to me what problem this solves. Maybe the problem no longer exsists in the new upstream release? Change-Id: I16762e0024536afb821eac70c6ba3929d5b8927a Reviewed-on: https://gerrit.libreoffice.org/36798 Reviewed-by: Michael Stahl <mstahl@redhat.com> Tested-by: Michael Stahl <mstahl@redhat.com>
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 Mac OS X 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