1179805 - Add compatibility check for glibc version

Status: RESOLVED FIXED

(Firefox Build System :: General, defect)

Description

[Dustin J. Mitchell [:dustin] (he/him)]

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.

Comment 1

[Mike Hommey [:glandium]]

(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.

Comment 2

[Mike Hommey [:glandium]]

Attachment: Add compatibility check for glibc version, like the one for libstdc++

At the same time, make the test for libstdc++ more comprehensible.

Comment 3

[Michael Shal [: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.

Comment 4

[Pulsebot]

https://hg.mozilla.org/integration/mozilla-inbound/rev/65117b62026a

Comment 5

[Carsten Book [:Tomcat]]

https://hg.mozilla.org/mozilla-central/rev/65117b62026a

Comment 6

[Dustin J. Mitchell [:dustin] (he/him)]

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.

Comment 7

[Ryan VanderMeulen [:RyanVM]]

Backed out at dustin's request over IRC.

https://hg.mozilla.org/integration/mozilla-inbound/rev/f6a5ad7edc09

Comment 8

[Dustin J. Mitchell [:dustin] (he/him)]

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.

Comment 9

[Pulsebot]

https://hg.mozilla.org/integration/mozilla-inbound/rev/e1d9c0f6bcb9

Comment 10

[Bill Gianopoulos [:WG9s]]

(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.

Comment 11

[Carsten Book [:Tomcat]]

https://hg.mozilla.org/mozilla-central/rev/e1d9c0f6bcb9

Comment 12

[Bill Gianopoulos [:WG9s]]

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