There's a name clash with the .pdb files that are part of ASan builds between
"rnp.exe" and "rnp.dll". This only happens on Windows builds. Renaming the CLI
executable will avoid the clash.
The automatically bootstrapped sysroots are not compatible with system
libraries pulled in with pkg-config. Using system_lib_option rather than
option still throws an error, but it provides a reason that is hopefully
less baffling than the generic error from pkg-config stating that the library
in question cannot be found.
Differential Revision: https://phabricator.services.mozilla.com/D126740
--HG--
extra : amend_source : 20d7e85bfab6bb081d46da82ded8db3c7756714d
Recent build changes for Firefox permit Thunderbird to drop
the libc++ dependency for official builds and link librnp.so
(Linux) against libstdc++, like the rest of the application.
This will reduce complexity of the build.
Depends on D123381 in mozilla-central.
Differential Revision: https://phabricator.services.mozilla.com/D123305
--HG--
extra : moz-landing-system : lando
This is counter-intuitive and may be a problem later since librnp.so now links
to libc++ (statically) and to libstdc++ dynamically. In theory it's "ok"
since everything was compiled with libc++ headers via "-stdlib=libc++".
stdc++-compat.o gets linked in whether we want it or not when "MOZ_STDCXX_COMPAT"
is set, with no obvious way to override that behavior.
Differential Revision: https://phabricator.services.mozilla.com/D123297
--HG--
extra : moz-landing-system : lando
Windows is of course the outlier, there is no "lib" prefix usually on sharted
libraries, but that is how OTRLib.jsm wants the file to be named so it's
artificially added where needed.
Differential Revision: https://phabricator.services.mozilla.com/D109489
--HG--
extra : moz-landing-system : lando
It's quite cumbersome to have the filename be versioned (eg. libotr.so.5) as
the way it's done is inconsistent between the supported platforms. Libtool
insists on using the full names, so bypass it with a link command that
sets the SONAME correctly as well.
Additionally, statically link the dependencies for Windows builds like the
other platforms.
Differential Revision: https://phabricator.services.mozilla.com/D109488
--HG--
rename : third_party/clang/aarch64-linux-gnu.cfg => third_party/clang/i686-linux-gnu.cfg
extra : moz-landing-system : lando
The newer version catches the libotr macOS regression at compiletime, which
is always better than when a user tries to use a feature.
--HG--
extra : rebase_source : 32fd7ba197bcf110d83e16aa9bdb00cc743a0d29
With the switch to a build sysroot, the linker is not able to locate libc++.a
and libc++abi.a on Linux64 builds (official builds with MOZ_STDCXX_COMPAT=1 only).
Adjust the path when linking librnp.so accordingly similarly to the Linux32
build.
This is not necessary for the Linux64-aarch64 build as it does not use libstdc++
compatibility mode.
Differential Revision: https://phabricator.services.mozilla.com/D106968
--HG--
extra : moz-landing-system : lando
This version fixes a compile error when building for linux-aarch64.
Differential Revision: https://phabricator.services.mozilla.com/D103001
--HG--
extra : rebase_source : 3aebc2380d6d2ab86c1cf1929b94f65bf704bc46
These will not be covered by CI for the moment because the global exclude does
not permit reincluding certain files. That deficiency in coverage can be addressed
in a follow-up bug.
Differential Revision: https://phabricator.services.mozilla.com/D95403
--HG--
extra : rebase_source : 984f3e236e2b0390ae9e374908d77fbf94603e5e
extra : histedit_source : b4e584a4c399820d36ba13eb44fe18c94d9252e0
When rnp_export.h was created in bug 1651031, the export symbols update script
stopped working as the C preprocessor could not find rnp_export.h in its include
path.
New symbols were also added.
Differential Revision: https://phabricator.services.mozilla.com/D95945
--HG--
extra : moz-landing-system : lando
Rob Lemley
Kai Engert
Geoff Lankow
Petr Sumbera