Closed Bug 1025639 Opened 10 years ago Closed 9 years ago

GCC 4.9 build issue.:toolkit/library/build/../../../content/media/MediaDecoderReader.o: requires dynamic R_X86_64_PC32 reloc against '_ZN7mozilla23AudioQueueMemoryFunctor12MallocSizeOfEPKv' which may overflow at runtime; recompile with -fPIC

Categories

(Firefox Build System :: General, defect)

Product:
Firefox Build System
Component:
General
Platform:
x86_64
All
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
RESOLVED WORKSFORME

People

(Reporter: ishikawa, Unassigned)

Details

Hi,

I tried to compile C-C thunderbird using GCC 4.9 under 64-bit linux(Debian GNU/linux amd64), and encounted a following error during
the linking of libxul.so.


/REF-OBJ-DIR/objdir-tb3 is my MOZ_OBJ,
/REF-COMM-CENTRAL/comm-central is my MOZ_SRC tree.

/usr/bin/ld.new: error: /REF-OBJ-DIR/objdir-tb3/mozilla/toolkit/library/build/../../../content/media/MediaDecoderReader.o: requires dynamic R_X86_64_PC32 reloc against '_ZN7mozilla23AudioQueueMemoryFunctor12MallocSizeOfEPKv' which may overflow at runtime; recompile with -fPIC
/usr/bin/ld.new: error: read-only segment has dynamic relocations
/REF-COMM-CENTRAL/comm-central/mozilla/content/media/MediaData.h:86: error: undefined reference to 'mozilla::AudioQueueMemoryFunctor::MallocSizeOf(void const*)'
/REF-COMM-CENTRAL/comm-central/mozilla/content/media/SharedBuffer.h:68: error: undefined reference to 'mozilla::AudioQueueMemoryFunctor::MallocSizeOf(void const*)'
collect2: error: ld returned 1 exit status
/REF-COMM-CENTRAL/comm-central/mozilla/config/rules.mk:882: recipe for target 'libxul.so' failed


I posted a question to mozilla.dev.build, and I got the following
suggestion from Mike Hommy there, but
still no go.

https://groups.google.com/forum/#!topic/mozilla.dev.builds/2kqJ2F7u3v8
>Sounds like namespace problems. Try replacing MallocSizeOf with
>mozilla::MallocSizeOf in content/media/MediaData.h and
>content/media/SharedBuffer.h.
>(And file a bug) 


Tool Information 

I am using split dwarf debug symbols for debugging local full build of
thunderbrid by using
-gsplit-dwarf, and GNU gold (git repository version refreshed a week
ago.) for fast and memory-efficient linking.

gcc --version
gcc-4.9 --version
gcc-4.9 (Debian 4.9.0-5) 4.9.0
Copyright (C) 2014 Free Software Foundation, Inc.

gcc-4.8 --version
gcc-4.8 (Debian 4.8.3-2) 4.8.3

GNU gold:
ld --version
GNU gold (GNU Binutils 2.24.51.20140610) 1.11

I got a link error as follows.

The same erro, even after changing the code as suggested :
    [...]
/usr/bin/ld.new: warning: hidden symbol 'pixman_glyph_cache_create' in /REF-OBJ-DIR/objdir-tb3/mozilla/toolkit/library/build/../../../gfx/cairo/libpixman/src/pixman-glyph.o is referenced by DSO /usr/lib/gcc/x86_64-linux-gnu/4.9/../../../x86_64-linux-gnu/libcairo.so
/usr/bin/ld.new: error: /REF-OBJ-DIR/objdir-tb3/mozilla/toolkit/library/build/../../../content/media/MediaDecoderReader.o: requires dynamic R_X86_64_PC32 reloc against '_ZN7mozilla23AudioQueueMemoryFunctor12MallocSizeOfEPKv' which may overflow at runtime; recompile with -fPIC
/usr/bin/ld.new: error: read-only segment has dynamic relocations
/REF-COMM-CENTRAL/comm-central/mozilla/content/media/MediaData.h:86: error: undefined reference to 'mozilla::AudioQueueMemoryFunctor::MallocSizeOf(void const*)'
/REF-COMM-CENTRAL/comm-central/mozilla/content/media/SharedBuffer.h:68: error: undefined reference to 'mozilla::AudioQueueMemoryFunctor::MallocSizeOf(void const*)'
     [...]

I got curious, and searched for MallocSizeOf in the source tree using
mxr.mozill.a.org.  After seeing so many instances of unqualified
MallocSizeOf references in source tree as well as qualified ones,
i.e., mozilla::MallocSizeof, and see the strange
"::AudioQueueMemoryFunctor::" in the error message, itt occurs to me
that the issue indeed may be a incorrect namespace specification (or
the slight interpretation change, either more correct or stricter or
whatever, introduced in gcc 4.9) in source files that refer the
functions MediaData.h and SharedBuffer.h, that is where MallocSizeOf
is called, but I am not sure.

TIA

PS: The reason I am using GNU gold git repository version is that GCC
4.8 produces a slightly correct debug symbol talbe when -gsplit-debug
is used, and the GNU Gold released in the spring of 2014, incorrectly
handles it and occasionally experiences SEGFAULT. (Older version like
last year's was OK.) I reported this problem with GNU gold to binutils
mailing list: Please see
https://sourceware.org/ml/binutils/2014-06/msg00088.html 
Thankfully, the problem is now fixed in GNU gold git repository
version.  
While debugging this issue, I was advised to try GCC 4.9 which produces
better debug symbol table [and the particular issue concerning the
incorrect debug table data is fixed in the latest 4.9], etc., and
encountered the issue above.
Please do not think this is TB-only. I got a private e-mail from someone who found
> firefox-beta 31 fails to build with gcc-4.9.
with the same issue above.

TIA
Can you try to just build mozilla-central? (not comm-central) I happen to have successfully built Firefox off mozilla-central yesterday, so if that works, that will eliminate a local toolchain problem.
(In reply to Mike Hommey [:glandium] from comment #2)
> Can you try to just build mozilla-central? (not comm-central) I happen to
> have successfully built Firefox off mozilla-central yesterday, so if that
> works, that will eliminate a local toolchain problem.

Will do tonight (JST).
TIA
Oh, I just realized I have 
ac_add_options --disable-gstreamer
in my mozconfig for C-C TB.
I doubt, though, if the person who had the similar issue in compiling
> firefox-beta 31 fails to build with gcc-4.9.
disabled gstreamer there.

TIA
A good news.
I refreshed C-C source tree a few hours ago, and let the compilation with GCC 4.9
and link under 64-bit environment. (Debian GNU/Linux AMD64)

It succeeds (!)
There have been many changes in the source files in the last two months, and so it is difficult to see what really changed the situation, but
I suspect the change to
mozilla/content/media/MediaData.h
might explain the disappearance of the particular error I reported here.
 
I have no idea how
> > firefox-beta 31 fails to build with gcc-4.9.
reported to me by someone else by e-mail can be fixed. Maybe backporting the change
to MediaData.h, and relevant changes to other files that are necessitated
by the change to MediaData.h?

I will report if the compilation using GCC 4.9 and GNU Gold under 32-bit Debian
GNU/Linux. It is proceeding, and take time on my slow PC. I hope I can report it tomorrow.

TIA
I forgot to mention that refreshing the source file now permits the
compilation and linking of firefox using the mozilla M-C portion of C-C source tree (under ./mozilla) to succeed also. (GCC 4.9, GNU gold, 64-bit Debian GNU/Linux amd64).

So I changed the Status to RESOLVED, WORKSFORME (maybe premature. But if the 32-bit compilation and linking still fails, I will re-open this.)

TIA
Status: NEW → RESOLVED
Closed: 10 years ago
Resolution: --- → WORKSFORME
Well, the beta tree is still broken.
Firefox beta1 & beta2 fails to build with gcc-4.9 on Mageia Linux.
See build logs at http://pkgsubmit.mageia.org/uploads/failure/cauldron/core/release/20140617110821.tv.valstar.13644/log/firefox-beta-31.0-0.b2.1.mga5/build.0.20140617110903.log

firefox 30 betas & final release builded fine with gcc-4.9...
That's a regression that needs to be fixed in the mozilla-beta branch before the ff 30 release.
Please reopen this bug.
Firefox 31.1 beta1 builds fine on Debian. What is your mozconfig?
You should try to build without the .spec and without the .mozconfig. If that still fails, that would indicate a problem with your toolchain (compiler or linker). Then try without the spec, but with the mozconfig. If that fails, that would be one of the options in the mozconfig. If it doesn't, it would be one of the flags that building the spec adds.
OK, I have re-opened this, but I think we need to have a clear idea of which branch(es) have issues with GCC 4.9 compilation and linking.

I have found that
- With C-C source tree refreshed on June 16-17 (JST is ahead of many time zones),
  -- mozilla firefox (under ./mozilla) directory could be compiled by GCC 4.9 and linked
     successfully under both 32-bit and 64-bit GNU Debian/linux.

  -- mozilla thunderbird (under ./ top directory) could be compiled by GCC 4.9 and
     linked successfully under 64-bit GNU Debian / linux 
     32-bit compilation is being checked (my guess would be it would be successful.)

from comment 7, comment 8, comment 9, comment 10:

 comment 8:
- mozilla Firefox 31.1 beta1 builds fine under GNU Debian linux using GCC 4.9
  (not sure which 32-bit, 64-bit?)

comment 7:
-  mozilla-beta branch before the ff 30 release failed to build using GCC 4.9

For the last issue, although there may be tool chain issues and configureation issues, looking at the recent changes to content/media/MediaData.h in the last two months, which seem to have fixed the compilation/linking issue,
(I get the same error under 32-bit before the refresh of the C-C source tree,
as in the log URL in comment 7)
I think backporting the change to earlier versions may be necessary for compilation with GCC 4.9.

The excerpt from the log URL in comment 7:
/../gfx/harfbuzz/src/hb-buffer.o is referenced by DSO /usr/lib/libpangoft2-1.0.so
/home/iurt/rpmbuild/BUILD/mozilla-beta/content/media/SharedBuffer.h:68: error: undefined reference to 'mozilla::AudioQueueMemoryFunctor::MallocSizeOf(void const*)'
/home/iurt/rpmbuild/BUILD/mozilla-beta/content/media/MediaData.h:86: error: undefined reference to 'mozilla::AudioQueueMemoryFunctor::MallocSizeOf(void const*)'
collect2: error: ld returned 1 exit status

The above is exactly the same error I saw under 32-bit Debian GNU/linux. (The error message issued by GNU gold under 64-bit which I saw may be misleading. It did not say, the symbol was undefined.)

TIA
Status: RESOLVED → REOPENED
Resolution: WORKSFORME → ---
Dear Thierry, 
do you still see this problem?
I think it is now taken care of in any of the major branches.
(Sorry I check mainly comm-central [and the exact copy of mozilla-central that is
under the ./mozilla subdirectory of comm-central tree.]
Flags: needinfo?(thierry.vignaud)
Thierry is away from home/office, but wrote to me by e-mail that the problem has been solved for several months.

So I am closing this bugzilla.
Status: REOPENED → RESOLVED
Closed: 10 years ago → 9 years ago
Resolution: --- → WORKSFORME
Flags: needinfo?(thierry.vignaud)
Product: Core → Firefox Build System
You need to log in before you can comment on or make changes to this bug.