Closed Bug 1179805 Opened 4 years ago Closed 4 years ago

Add compatibility check for glibc version

Categories

(Firefox Build System :: General, defect)

defect
Not set

Tracking

(firefox44 fixed)

RESOLVED FIXED
mozilla44
Tracking Status
firefox44 --- fixed

People

(Reporter: dustin, Assigned: glandium)

References

Details

Attachments

(1 file)

We have some checks to make sure that Firefox is compatible with older versions of gtk+3, regardless of what it's linked aginst at build time, and we should do the same for glibc.
(In reply to Dustin J. Mitchell [:dustin] from comment #0)
> We have some checks to make sure that Firefox is compatible with older
> versions of gtk+3

s/gtk+3/libstdc++/

So for prospective assignees, what would need to be replicated is CHECK_STDCXX.
At the same time, make the test for libstdc++ more comprehensible.
Assignee: nobody → mh+mozilla
Attachment #8630375 - Flags: review?(mshal)
Comment on attachment 8630375 [details] [diff] [review]
Add compatibility check for glibc version, like  the one for libstdc++

> ifneq (,$(MOZ_LIBSTDCXX_TARGET_VERSION)$(MOZ_LIBSTDCXX_HOST_VERSION))
> ifneq ($(OS_ARCH),Darwin)

Is the Darwin check necessary anymore? It seems the first if check will only be true if the mozconfig specifies --enable-stdcxx-compat, though I may be reading that wrong.

>+CHECK_STDCXX = $(call CHECK_SYMBOLS,$(1),GLIBCXX,libstdc++,v[1] > 3 || (v[1] == 3 && v[2] == 4 && v[3] >= 11))
>+CHECK_GLIBC = $(call CHECK_SYMBOLS,$(1),GLIBC,libc,v[1] > 2 || (v[1] == 2 && v[2] > 7))

Can you either use >= in both or > in both for the last check? It's a little odd to have 3.4.11 as the first bad version and 2.7 as the last good version.
Attachment #8630375 - Flags: review?(mshal) → review+
https://hg.mozilla.org/mozilla-central/rev/65117b62026a
Status: NEW → RESOLVED
Closed: 4 years ago
Resolution: --- → FIXED
Target Milestone: --- → Firefox 42
Depends on: 1181568
Since we don't yet pass this check in TaskCluster (bug 1179818), I'd like to roll this back until we do.  Otherwise, we're artificially preventing other work from being done, since the builds fail on this check.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Backed out at dustin's request over IRC.

https://hg.mozilla.org/integration/mozilla-inbound/rev/f6a5ad7edc09
Target Milestone: Firefox 42 → ---
Depends on: 1179818
Depends on: 1189892
I think we can re-land this now.  Try run:
  https://treeherder.mozilla.org/#/jobs?repo=try&revision=18b58662c749
If that goes green, I'll re-land, unless there are other objections.
(In reply to Dustin J. Mitchell [:dustin] from comment #8)
> I think we can re-land this now.  Try run:
>   https://treeherder.mozilla.org/#/jobs?repo=try&revision=18b58662c749
> If that goes green, I'll re-land, unless there are other objections.

I have a workaround for my issue.  I would prefer a minimum glibc version supported configure option though.
https://hg.mozilla.org/mozilla-central/rev/e1d9c0f6bcb9
Status: REOPENED → RESOLVED
Closed: 4 years ago4 years ago
Resolution: --- → FIXED
Target Milestone: --- → Firefox 44
For those using a reasonably recent Linux distro for which this causes issues, here is the patch I am using to workaround the issue.  http://www.wg9s.com/mozilla/firefox/patches/wg9s2.diff
Component: Build Config → General
Product: Firefox → Firefox Build System
Target Milestone: Firefox 44 → mozilla44
You need to log in before you can comment on or make changes to this bug.