Closed Bug 1633778 Opened 5 years ago Closed 5 years ago

Update build/runtime requirements for Linux with regard to inclusion of OpenPGP libraries

Categories

(Thunderbird :: Build Config, task)

Product:
Thunderbird
Component:
Build Config
Type:
task

Tracking

(Not tracked)

Status:
RESOLVED FIXED
Milestone:
Thunderbird 78.0

People

(Reporter: rjl, Assigned: rjl)

References

(Blocks 1 open bug)

Details

Attachments

(1 file)

Port bug 1634204: Upgrade Linux build docker images to Debian 8 base
10.42 KB, patch
darktrojan
: review+
Details | Diff | Splinter Review

With the addition of the OpenPGP libraries, the minimum libstdc++ requirement has gone up to 4.8 (currently 4.6.1).

The current minimum libstdc++ is 4.6.1 or higher. I understand that to really mean "GCC 4.6.1: GLIBCXX_3.4.16, CXXABI_1.3.5" https://www.thunderbird.net/en-US/thunderbird/68.7.0/system-requirements/

Botan requires GCC 4.8+: https://botan.randombit.net/handbook/support.html

I translate that to line up with libstdc++ 4.8+.

Currently, the check for libstdc++ symbols that are "too new" is disabled for librnp.so as we get these errors on Taskcluster:

make[4]: Entering directory '/builds/worker/workspace/obj-build/comm/third_party/rnp'
/builds/worker/workspace/obj-build/_virtualenvs/init_py3/bin/python -m mozbuild.action.check_binary --target librnp.so
TEST-UNEXPECTED-FAIL | check_stdcxx | librnp.so | We do not want these libstdc++ symbol versions to be used:
 _ZNSt6chrono3_V212system_clock3nowEv (GLIBCXX_3.4.19)
 _ZTINSt6thread6_StateE (GLIBCXX_3.4.22)
 _ZNSt3_V216generic_categoryEv (GLIBCXX_3.4.21)
 _ZNSt28__atomic_futex_unsigned_base19_M_futex_notify_allEPj (GLIBCXX_3.4.21)
_ZNSt28__atomic_futex_unsigned_base19_M_futex_wait_untilEPjjbNSt6chrono8durationIlSt5ratioILl1ELl1EEEENS2_IlS3_ILl1ELl1000000000EEEE (GLIBCXX_3.4.21)
TEST-PASS | check_libgcc | librnp.so
TEST-PASS | check_glibc | librnp.so
TEST-PASS | check_textrel | librnp.so
/builds/worker/checkouts/gecko/config/rules.mk:608: recipe for target 'librnp.so' failed
make[4]: *** [librnp.so] Error 1

As I understand it, we have a couple of options:
1 - Add the above to build/unix/stdc++compat (and write whatever code to make it work)
2 - Bump the minimum libstdc++ requirement to 4.8

According https://developer.mozilla.org/en-US/docs/Mozilla/Firefox/Linux_compatibility_matrix,
Redhat/Centos 6 will have compatibility issues with the current builds. The EOL is listed as November 2020. It looks like all other currently supported distributions will be okay.
It's definitely easier to bump the minimum required version if that's acceptable.

Jan, Martin, do you intend to rebase to TB 78 on RHEL 6.x ?

Flags: needinfo?(jhorak)

Rob, is it clear who will decide about your suggestion?

I've added glandium to CC, as he edited the linked wiki page most often in recent years.
Mike, what do you think?

Flags: needinfo?(mh+mozilla)

With the addition of the OpenPGP libraries, the minimum libstdc++ requirement has gone up to 4.8

How is openpgp involved in that?

(currently 4.6.1).

Actually... as of bug 1536307, it's 4.7. I forgot to flag to update the system requirements. Jcristau, are you the right person to update that?

As I understand it, we have a couple of options:
1 - Add the above to build/unix/stdc++compat (and write whatever code to make it work)
2 - Bump the minimum libstdc++ requirement to 4.8

Considering the list of errors you have, it's not an either/or choice, you need both, because one of the symbols is from 6.0.

The Linux compat table would need to be refreshed and more investigation done, but at quick glance, it seems that bumping to 5.0 /might/ be a reasonable thing to do, even for Firefox.

Flags: needinfo?(mh+mozilla) → needinfo?(jcristau)

I've updated system-requirements for all firefox 68+ releases.

Flags: needinfo?(jcristau)

(In reply to Mike Hommey [:glandium] from comment #3)

Considering the list of errors you have, it's not an either/or choice, you need both, because one of the symbols is from 6.0.

You're referring to these symbols, which require "newer than 4.8.1":

(In reply to Rob Lemley [:rjl] from comment #0)

_ZTINSt6thread6_StateE (GLIBCXX_3.4.22)
_ZNSt3_V216generic_categoryEv (GLIBCXX_3.4.21)
_ZNSt28__atomic_futex_unsigned_base19_M_futex_notify_allEPj (GLIBCXX_3.4.21)
_ZNSt28__atomic_futex_unsigned_base19_M_futex_wait_untilEPjjbNSt6chrono8durationIlSt5ratioILl1ELl1EEEENS2_IlS3_ILl1ELl1000000000EEEE (GLIBCXX_3.4.21)

Rob, what compiler and stdc++ version did you use at build time?

I've made a test and built on latest CentOS 7, which has gcc and libstdc++ version 4.8.5.

Checking resulting libbotan.so with llvm-objdump -T reports a maximum symbol of @GLIBCXX_3.4.19, I don't see 3.4.21/3.4.22, so maybe what you got were indirect requirements, caused by building with newer software?

(In reply to Mike Hommey [:glandium] from comment #3)

How is openpgp involved in that?

Can you please clarify your question? We'll include libraries with Thunderbird to support OpenPGP email messaging. That means the RNP library, which depends on the Botan library.

Okay, I got it down to just one symbol (which is from 4.8.1). The missing piece was the Visibility flags.

INFO -  make[4]: Entering directory '/builds/worker/workspace/obj-build/comm/third_party/rnp'
INFO -  /builds/worker/workspace/obj-build/_virtualenvs/init_py3/bin/python -m mozbuild.action.check_binary --target librnp.so
INFO -  TEST-UNEXPECTED-FAIL | check_stdcxx | librnp.so | We do not want these libstdc++ symbol versions to be used:
INFO -   _ZNSt6chrono3_V212system_clock3nowEv (GLIBCXX_3.4.19)
INFO -  TEST-PASS | check_libgcc | librnp.so
INFO -  TEST-PASS | check_glibc | librnp.so
INFO -  TEST-PASS | check_textrel | librnp.so
INFO -  /builds/worker/checkouts/gecko/config/rules.mk:608: recipe for target 'librnp.so' failed
ERROR -  make[4]: *** [librnp.so] Error 1

If bumping the requirement to libstdc++5.0 is a possibility then we should be good.

Mike, if CentOS 7.x has only 4.8.x (latest has 4.8.5), why did you suggest to bump the requirement to 5.0 ?

Requiring 4.8.1 seems sufficient.

(In reply to Kai Engert (:KaiE:) from comment #1)

Jan, Martin, do you intend to rebase to TB 78 on RHEL 6.x ?

I think we no longer need the answer to this question. I see that CentOS 6 shipped Thunderbird 68, despite the requirement to use libstdc++ 4.6, and despite CentOS 6 being listed as having 4.4. (I'm guessing they have found a way to work around that limitation, possibly by shipping the newer libstdc++ as an additional package.)

Flags: needinfo?(jhorak)

(In reply to Kai Engert (:KaiE:) from comment #6)

(In reply to Mike Hommey [:glandium] from comment #3)

How is openpgp involved in that?

Can you please clarify your question? We'll include libraries with Thunderbird to support OpenPGP email messaging. That means the RNP library, which depends on the Botan library.

Well, rnp+botan is the piece that was missing. I didn't see the link between openpgp and C++...

despite the requirement to use libstdc++ 4.6

Note that that requirement is a runtime requirement for the Firefox binary that Mozilla ships.

(In reply to Mike Hommey [:glandium] from comment #11)

Note that that requirement is a runtime requirement for the Firefox binary that Mozilla ships.

Thanks for clarifying. I've installed CentOS 6.10 in a VM to clarify. Thunderbird 68 on CentOS 6.10 links with libstdc++ version 4.4.7.

(In reply to Kai Engert (:KaiE:) from comment #8)

Mike, if CentOS 7.x has only 4.8.x (latest has 4.8.5), why did you suggest to bump the requirement to 5.0 ?

Requiring 4.8.1 seems sufficient.

Because if we're going to bump, we might as well explore reasonable options. It seems the only distro that has libstdc++ < 5 and that is still currently supported by Firefox and not EOL is Debian 8, which EOLs in June, so before 78 is actually released. Bumping to 5 would remove the need for _GLIBCXX_USE_CXX11_ABI=0.

Depends on: 1634209

It seems the only distro that has libstdc++ < 5 and that is still currently supported by Firefox and not EOL is Debian 8

I stand corrected, RHEL7 is another, and it has 4.8.5 and is not EOL until at least 2023 (although the compat matrix says 2024 ; I've found contradicting information around that, but it won't matter until then).

Replaces the debian7 images with debian8. Port of D73784.
Attachment #9145928 - Flags: review?(geoff)
Assignee: nobody → rob
Status: NEW → ASSIGNED

Need to port D73784 from bug 1634204.

Depends on: 1634204
Comment on attachment 9145928 [details] [diff] [review] Port bug 1634204: Upgrade Linux build docker images to Debian 8 base Review of attachment 9145928 [details] [diff] [review]: ----------------------------------------------------------------- This looks okay to me. I was going to fix the nit and land this (as the m-c bug landed and I think we need it) but it looks like we have other problems at the moment anyway. ::: taskcluster/ci/config.yml @@ +9,5 @@ > treeherder: > group-names: > # Images/Packages/Toolchain > + 'Deb8': 'Packages for Debian 7' > + 'Deb8-32': 'Packages for Debian 7 32-bits' Should say 8 instead of 7.
Attachment #9145928 - Flags: review?(geoff) → review+

Pushed by mkmelin@iki.fi:
https://hg.mozilla.org/comm-central/rev/5a1303612c72
Port bug 1634204: Upgrade Linux build docker images to Debian 8 base. r=darktrojan DONTBUILD

Status: ASSIGNED → RESOLVED
Closed: 5 years ago
Resolution: --- → FIXED
Target Milestone: --- → Thunderbird 78.0
Backout by thunderbird@calypsoblue.org: https://hg.mozilla.org/comm-central/rev/a8c798beb1c1 Backed out changeset 5a1303612c72 , M-C build failures. a=backout
Pushed by geoff@darktrojan.net: https://hg.mozilla.org/comm-central/rev/5559a05ade37 Port bug 1634204: Upgrade Linux build docker images to Debian 8 base. r=darktrojan

I had to add a few changes to fix the decision task. (Okay the last one was unnecessary but it seemed like it should be there.)

You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: