Aurora nightlies failing after uplift with many "undefined reference to `mozilla::a11y::logging::IsEnabled(unsigned int)'" errors

RESOLVED DUPLICATE of bug 932153

Status

()

--
blocker
RESOLVED DUPLICATE of bug 932153
5 years ago
5 years ago

People

(Reporter: cbook, Unassigned)

Tracking

Trunk
x86
All
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

5 years ago
Nightly Builds on Aurora fail for Linux, Mac and Android so far

Logs Linux: https://tbpl.mozilla.org/php/getParsedLog.php?id=29825388&tree=Mozilla-Aurora

Android: https://tbpl.mozilla.org/php/getParsedLog.php?id=29824829&tree=Mozilla-Aurora

and Mac:
https://tbpl.mozilla.org/php/getParsedLog.php?id=29825650&tree=Mozilla-Aurora

Marco, i wonder why this seems to fail somewhere in build/accessible/src/xul/XULElementAccessibles.cpp is this something for you ?

Updated

5 years ago
Blocks: 932211

Comment 1

5 years ago
* On trunk, the update channel is either "default" (standard builds) or "nightly" (nightly 'Nightly' builds).
* On aurora, the update channel is either "default" (standard builds) or "aurora" (nightly Aurora builds).
* In the 'default' and 'nightly' case (ie everything but the nightlies on aurora), we enable a11y logging in several places:
http://mxr.mozilla.org/mozilla-central/source/accessible/src/shared.mozbuild#11
11 if CONFIG['MOZ_UPDATE_CHANNEL'] not in ('aurora', 'beta', 'release', 'esr'):
12     a11y_log = 1
...and:
http://mxr.mozilla.org/mozilla-central/source/accessible/src/Makefile.in#9
9 ifeq (,$(filter aurora beta release esr,$(MOZ_UPDATE_CHANNEL)))
10   A11Y_LOG = 1
11 endif
(plus some more)

Seems like the "logging disabled" case was landed broken or else has broken since.

With logging disabled we don't build:
http://mxr.mozilla.org/mozilla-central/source/accessible/src/base/moz.build#60
60 if a11y_log:
61     SOURCES += [
62         'Logging.cpp',
63     ]

Guessing we are missing some #ifdef A11Y_LOG wrapping in a few places.
Component: General → Disability Access APIs
Summary: Aurora Nightly Build Bustage due to /usr/bin/ld: final link failed: Nonrepresentable section on output in XULElementAccessibles.cpp → Aurora nightlies failing after uplift with many "undefined reference to `mozilla::a11y::logging::IsEnabled(unsigned int)'" errors

Comment 2

5 years ago
Strange, the |#ifdef A11Y_LOG| wrapping seems fine, eg:
http://mxr.mozilla.org/mozilla-central/source/accessible/src/xul/XULElementAccessibles.cpp#109

Smells like an issue with the defines in the build configs maybe?

They are a bit all over the place (quite a lot of duplication and unnecessary comparisons to zero?!)

Using:
http://mxr.mozilla.org/mozilla-central/search?string=A11Y_LOG

Gets us:

http://mxr.mozilla.org/mozilla-central/source/accessible/src/Makefile.in#10
5 A11Y_LOG = 0
6 ifdef MOZ_DEBUG
7   A11Y_LOG = 1
8 endif
9 ifeq (,$(filter aurora beta release esr,$(MOZ_UPDATE_CHANNEL)))
10   A11Y_LOG = 1
11 endif
12 export A11Y_LOG

http://mxr.mozilla.org/mozilla-central/source/accessible/src/shared.mozbuild#12
7 a11y_log = 0
8 if CONFIG['MOZ_DEBUG']:
9     a11y_log = 1
10 
11 if CONFIG['MOZ_UPDATE_CHANNEL'] not in ('aurora', 'beta', 'release', 'esr'):
12     a11y_log = 1

This pattern:
17 ifneq ($(A11Y_LOG),0)
18   DEFINES += -DA11Y_LOG
19 endif
...is used by:
http://mxr.mozilla.org/mozilla-central/source/accessible/src/atk/Makefile.in#18
http://mxr.mozilla.org/mozilla-central/source/accessible/src/base/Makefile.in#12
http://mxr.mozilla.org/mozilla-central/source/accessible/src/generic/Makefile.in#8
http://mxr.mozilla.org/mozilla-central/source/accessible/src/html/Makefile.in#9
http://mxr.mozilla.org/mozilla-central/source/accessible/src/mac/Makefile.in#9
http://mxr.mozilla.org/mozilla-central/source/accessible/src/other/Makefile.in#9
http://mxr.mozilla.org/mozilla-central/source/accessible/src/xpcom/Makefile.in#17
http://mxr.mozilla.org/mozilla-central/source/accessible/src/xul/Makefile.in#9
http://mxr.mozilla.org/mozilla-central/source/accessible/src/windows/Makefile.in#9
http://mxr.mozilla.org/mozilla-central/source/accessible/src/windows/msaa/Makefile.in#8

This pattern:
13 ifdef A11Y_LOG
14   DEFINES += -DA11Y_LOG
15 endif
...is used by:
http://mxr.mozilla.org/mozilla-central/source/accessible/src/windows/uia/Makefile.in#14
http://mxr.mozilla.org/mozilla-central/source/accessible/src/windows/ia2/Makefile.in#12

Comment 3

5 years ago
gps, the patterns used in comment 2 seem suboptimal - is there a better way for the a11y team to set this up?  Also is the preferred way to have the define set in configure or in the individual makefiles?
Flags: needinfo?(gps)

Comment 4

5 years ago
I'm struggling to find anything that landed in the mozilla27 timeframe that could have regressed this.

Would removing the boilerplate here have affected the export?
http://hg.mozilla.org/mozilla-central/diff/45097bc3a578/accessible/src/Makefile.in

Comment 5

5 years ago
This is keeping aurora closed.
status-firefox27: --- → affected
tracking-firefox28: --- → ?
Flags: needinfo?(surkov.alexander)

Comment 6

5 years ago
Ah, this will be fixed by bug 932153.

tl;dr in a non-recursive build, you can't rely on A11Y_LOG being exported from accessible/src/Makefile.in

gps, leaving the needinfo to see if there is a more cleanup that can be done other than the patch in bug 932153.
No longer blocks: 932211
Status: NEW → RESOLVED
Last Resolved: 5 years ago
status-firefox27: affected → ---
tracking-firefox28: ? → ---
Flags: needinfo?(surkov.alexander)
Resolution: --- → DUPLICATE
Duplicate of bug: 932153
(In reply to Ed Morley [:edmorley UTC+1] from comment #6)
> gps, leaving the needinfo to see if there is a more cleanup that can be done
> other than the patch in bug 932153.

There's a lot of cleanup that can be done. But not to uplift imho.

Comment 8

5 years ago
(In reply to Mike Hommey [:glandium] from comment #7)
> There's a lot of cleanup that can be done. But not to uplift imho.

Happy to file a bug (for trunk) based on the suggestions from yourself/gps :-)

Comment 9

5 years ago
We should keep one of these bugs open to track a longer-term solution.
Flags: needinfo?(gps)
(In reply to Gregory Szorc [:gps] from comment #9)
> We should keep one of these bugs open to track a longer-term solution.

I've filed bug 935548 for the further cleanup :-)
You need to log in before you can comment on or make changes to this bug.