Closed
Bug 1293928
Opened 7 years ago
Closed 7 years ago
Linux* nightly busted with bin/ld: read-only segment has dynamic relocations.
Categories
(SeaMonkey :: Build Config, defect)
SeaMonkey
Build Config
Tracking
(seamonkey2.45 fixed, seamonkey2.46 fixed, seamonkey2.47 fixed, seamonkey2.48 affected)
RESOLVED
FIXED
seamonkey2.46
People
(Reporter: ewong, Assigned: ewong)
References
Details
Attachments
(4 files)
2.02 KB,
patch
|
philip.chee
:
review+
ewong
:
approval-comm-aurora+
ewong
:
approval-comm-beta+
ewong
:
approval-comm-release+
|
Details | Diff | Splinter Review |
8.66 MB,
text/x-log
|
Details | |
912 bytes,
text/plain
|
Details | |
128.62 KB,
text/plain
|
Details |
/builds/slave/c-cen-t-lnx-ntly/build/gcc/bin/../lib/gcc/x86_64-unknown-linux-gnu/4.8.5/../../../../x86_64-unknown-linux-gnu/bin/ld: read-only segment has dynamic relocations. collect2: error: ld returned 1 exit status make[4]: *** [libxul.so] Error 1 make[4]: Leaving directory `/builds/slave/c-cen-t-lnx-ntly/build/objdir/toolkit/library' make[3]: *** [toolkit/library/target] Error 2 make[3]: Leaving directory `/builds/slave/c-cen-t-lnx-ntly/build/objdir' make[2]: *** [compile] Error 2 make[2]: Leaving directory `/builds/slave/c-cen-t-lnx-ntly/build/objdir' make[1]: *** [default] Error 2 make[1]: Leaving directory `/builds/slave/c-cen-t-lnx-ntly/build/objdir' make: *** [build] Error 2
![]() |
Assignee | |
Comment 1•7 years ago
|
||
![]() |
Assignee | |
Comment 2•7 years ago
|
||
a bit more context as to where it's choking: INPUT("../../gfx/skia/Unified_cpp_gfx_skia3.o") INPUT("../../gfx/skia/Unified_cpp_gfx_skia4.o") INPUT("../../gfx/skia/Unified_cpp_gfx_skia5.o") INPUT("../../gfx/skia/Unified_cpp_gfx_skia6.o") INPUT("../../gfx/skia/Unified_cpp_gfx_skia7.o") INPUT("../../gfx/skia/Unified_cpp_gfx_skia8.o") INPUT("../../gfx/skia/Unified_cpp_gfx_skia9.o") INPUT("../../modules/zlib/src/adler32.o") INPUT("../../modules/zlib/src/compress.o") INPUT("../../modules/zlib/src/crc32.o") INPUT("../../modules/zlib/src/deflate.o") INPUT("../../modules/zlib/src/gzclose.o") INPUT("../../modules/zlib/src/gzlib.o") INPUT("../../modules/zlib/src/gzread.o") INPUT("../../modules/zlib/src/gzwrite.o") INPUT("../../modules/zlib/src/infback.o") INPUT("../../modules/zlib/src/inffast.o") INPUT("../../modules/zlib/src/inflate.o") INPUT("../../modules/zlib/src/inftrees.o") INPUT("../../modules/zlib/src/trees.o") INPUT("../../modules/zlib/src/uncompr.o") INPUT("../../modules/zlib/src/zutil.o") INPUT("StaticXULComponentsEnd/StaticXULComponentsEnd.o") /builds/slave/c-cen-t-lnx-ntly/build/gcc/bin/../lib/gcc/x86_64-unknown-linux-gnu/4.8.5/../../../../x86_64-unknown-linux-gnu/bin/ld: /lib64/libz.so.1: no version information available (required by /builds/slave/c-cen-t-lnx-ntly/build/gcc/bin/../lib/gcc/x86_64-unknown-linux-gnu/4.8.5/../../../../x86_64-unknown-linux-gnu/bin/ld) /builds/slave/c-cen-t-lnx-ntly/build/gcc/bin/../lib/gcc/x86_64-unknown-linux-gnu/4.8.5/../../../../x86_64-unknown-linux-gnu/bin/ld: read-only segment has dynamic relocations. collect2: error: ld returned 1 exit status make[4]: *** [libxul.so] Error 1 make[4]: Leaving directory `/builds/slave/c-cen-t-lnx-ntly/build/objdir/toolkit/library' make[3]: *** [toolkit/library/target] Error 2 make[3]: Leaving directory `/builds/slave/c-cen-t-lnx-ntly/build/objdir' make[2]: *** [compile] Error 2 make[2]: Leaving directory `/builds/slave/c-cen-t-lnx-ntly/build/objdir' make[1]: *** [default] Error 2 make[1]: Leaving directory `/builds/slave/c-cen-t-lnx-ntly/build/objdir' make: *** [build] Error 2
![]() |
Assignee | |
Comment 3•7 years ago
|
||
https://hg.mozilla.org/comm-central/rev/8f57173fe6a885b1de01b1e9510a3ad8e3f45753 Bug 1293928 - Update gcc 4.8.5 w/ PR64905 tooltool to fix Nightly bustage. (port bug 1261264 to SeaMonkey r+a=bustagefix
![]() |
Assignee | |
Comment 4•7 years ago
|
||
Comment on attachment 8779611 [details] [diff] [review] [tooltool] proposed patch (update gcc tooltool package) [checked-in] [Approval Request Comment] Regression caused by (bug #): User impact if declined: Testing completed (on m-c, etc.): Risk to taking this patch (and alternatives if risky): String changes made by this patch: This fixes the bustage. If I take TB's version's push date, then this patch was supposed to be pushed in April. And since I only recently pushed this patch to c-c (post-merge), and c-a is currently busted on Linux64 (bug 1295399) with a similar issue, I believe that this patch should be uplifted to c-a.
Attachment #8779611 -
Flags: approval-comm-aurora?
![]() |
Assignee | |
Comment 5•7 years ago
|
||
(In reply to Edmund Wong (:ewong) from comment #4) > Comment on attachment 8779611 [details] [diff] [review] > [tooltool] proposed patch (update gcc tooltool package) > > [Approval Request Comment] > Regression caused by (bug #): > User impact if declined: build bustage on linux64 > Testing completed (on m-c, etc.): > Risk to taking this patch (and alternatives if risky): > String changes made by this patch: None > (again.. enter-trigger-happy finger.. )
![]() |
Assignee | |
Updated•7 years ago
|
Attachment #8779611 -
Attachment description: [tooltool] proposed patch (update gcc tooltool package) → [tooltool] proposed patch (update gcc tooltool package) [checked-in]
![]() |
Assignee | |
Comment 6•7 years ago
|
||
(In reply to Edmund Wong (:ewong) from comment #5) > (In reply to Edmund Wong (:ewong) from comment #4) > > Comment on attachment 8779611 [details] [diff] [review] > > [tooltool] proposed patch (update gcc tooltool package) > > > > [Approval Request Comment] > > Regression caused by (bug #): 1261264
![]() |
Assignee | |
Comment 7•7 years ago
|
||
https://hg.mozilla.org/releases/comm-aurora/rev/4fd1aadbbd5cd5d29645a83fffb5436da3b1d7c4 Bug 1293928 - Update gcc 4.8.5 w/ PR64905 tooltool to fix bustage. (port bug 1261264 to SeaMonkey) r+a=bustagefix
![]() |
Assignee | |
Updated•7 years ago
|
Attachment #8779611 -
Flags: approval-comm-aurora? → approval-comm-aurora+
![]() |
Assignee | |
Comment 8•7 years ago
|
||
Seems like the patch unhorked the c-a build... nice!
![]() |
Assignee | |
Comment 10•7 years ago
|
||
Comment on attachment 8779611 [details] [diff] [review] [tooltool] proposed patch (update gcc tooltool package) [checked-in] [Triage Comment] [Triage Comment] this needs to be uplifted to c-r, and might as well uplift it to c-b as well. got IanN's a+ for both over IRC
Attachment #8779611 -
Flags: approval-comm-release+
Attachment #8779611 -
Flags: approval-comm-beta+
![]() |
||
Comment 11•7 years ago
|
||
Comment on attachment 8779611 [details] [diff] [review] [tooltool] proposed patch (update gcc tooltool package) [checked-in] rs=me
Attachment #8779611 -
Flags: review?(philip.chee) → review+
![]() |
Assignee | |
Comment 12•7 years ago
|
||
https://hg.mozilla.org/releases/comm-release/rev/b5dd8faf93dfdecd40861e7dfe83631468ac9e4d Bug 1293928 - Bug 1293928 - Update gcc 4.8.5 w/ PR64905 tooltool to fix bustage. (port bug 1261264 to SeaMonkey) r=RattyAway a=IanN
![]() |
Assignee | |
Updated•7 years ago
|
Status: ASSIGNED → RESOLVED
Closed: 7 years ago
status-seamonkey2.45:
--- → fixed
status-seamonkey2.46:
--- → fixed
status-seamonkey2.47:
--- → fixed
status-seamonkey2.48:
--- → fixed
Resolution: --- → FIXED
Target Milestone: --- → seamonkey2.46
![]() |
Assignee | |
Comment 13•7 years ago
|
||
was wrong.. apparently this isn't fixed.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
![]() |
Assignee | |
Updated•7 years ago
|
Status: REOPENED → ASSIGNED
![]() |
Assignee | |
Comment 14•7 years ago
|
||
(In reply to Edmund Wong (:ewong) from comment #13) > was wrong.. apparently this isn't fixed. on second thoughts.. Aug 25 17:00 b05a1a42ab82 success #7536 Build successful Aug 25 17:13 b05a1a42ab82 failure #7537 Failed compile Makes no sense since the m-c changes between 17:00 and 17:13 was only : http://hg.mozilla.org/mozilla-central/rev/a551f534773c and this seriously won't bust this way.. I've backed out my puppet whitelist dbg clobber patch and retriggered.
![]() |
Assignee | |
Comment 15•7 years ago
|
||
Fri Sep 9 02:35:32 2016's build was green. built with: c-a : http://hg.mozilla.org/releases/comm-aurora/rev/ac425c17800f m-a : http://hg.mozilla.org/releases/mozilla-aurora/rev/6cd56350a895 Then: Sat Sep 10 01:30:02 2016's build is busted with this error. which was built with: c-a : http://hg.mozilla.org/releases/comm-aurora/rev/6e41f3a00c6b m-a : http://hg.mozilla.org/releases/mozilla-aurora/rev/28878b37a89e
![]() |
Assignee | |
Comment 16•7 years ago
|
||
Build log
![]() |
Assignee | |
Comment 17•7 years ago
|
||
![]() |
Assignee | |
Comment 18•7 years ago
|
||
https://hg.mozilla.org/SeaMonkey/puppet/rev/d48761db4d181d55cdcb5c8ee5b20ff71323df72 Whitelist c-aurora-lnx-ntly to figure out Bug 1293928
![]() |
Assignee | |
Comment 19•7 years ago
|
||
it's now building.. with the following csets: c-a: http://hg.mozilla.org/releases/comm-aurora/rev/a8ddbce782b0 m-a: http://hg.mozilla.org/releases/mozilla-aurora/rev/2c332306c030
Comment 20•7 years ago
|
||
What's happening to ewong: approval-comm-beta+ ? Is this ever going to land on any beta or can this be cleared?
Flags: needinfo?(ewong)
![]() |
Assignee | |
Comment 21•7 years ago
|
||
(In reply to Jorg K (GMT+2) from comment #20) > What's happening to ewong: approval-comm-beta+ ? > Is this ever going to land on any beta or can this be cleared? pardon my confusion, but I think it looks like this bug can be closed... (unless I missed something) because c-a, c-b and c-r all have this patch either merged or pushed.
Status: ASSIGNED → RESOLVED
Closed: 7 years ago → 7 years ago
Flags: needinfo?(ewong)
Resolution: --- → FIXED
Comment 22•7 years ago
|
||
OK, here is it on beta: https://hg.mozilla.org/releases/comm-beta/rev/4fd1aadbbd5c (I need this comment or else I will forever find this bug with approval but no landing.)
![]() |
Assignee | |
Comment 23•7 years ago
|
||
In a recent c-b build, it's busted again with the same issue so I'm reopening this. Last good cset: c-b: http://hg.mozilla.org/releases/comm-beta/rev/7921f6517883 m-b: http://hg.mozilla.org/releases/mozilla-beta/rev/27ce6db0b235 First bad cset: c-b: http://hg.mozilla.org/releases/comm-beta/rev/7921f6517883 m-b: http://hg.mozilla.org/releases/mozilla-beta/rev/68b9c9dc4612 So: http://hg.mozilla.org/releases/mozilla-beta/pushloghtml?fromchange=27ce6db0b235&tochange=68b9c9dc4612 Colour me stumped again. Just retriggered it.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
![]() |
Assignee | |
Comment 24•7 years ago
|
||
having retriggered a c-b linux build three times, it's finally working. It failed on -5 and -6, but works with -10. I'm guessing there's something weird with -5 and -6.
![]() |
Assignee | |
Comment 25•7 years ago
|
||
Updated•7 years ago
|
Attachment #8796485 -
Attachment mime type: text/x-log → text/plain
![]() |
Assignee | |
Comment 26•7 years ago
|
||
On irc, glandium mentioned that we shouldn't be building closures.c, but looking at the following: ar t /builds/slave/rel-c-rel-lnx-bld/build/objdir/config/external/libffi/.libs/libffi.a, I get: prep_cif.o types.o raw_api.o java_raw_api.o closures.o ffi.o sysv.o win32.o So closures.o is included, which is (afaict and according to what glandium mentioned), this is what's giving us a linking error. Looking at http://hg.mozilla.org/releases/mozilla-release/file/tip/js/src/ctypes/libffi/Makefile.in#l699 it does include closures.c so any fix will need to be sent upstream? am I right glandium or is there an alternative solution? somewhat similar to bug 1306543 I guess?
Flags: needinfo?(mh+mozilla)
Comment 27•7 years ago
|
||
It turns out we *are* building closures.c. I thought we weren't, but we are. No, the *real* problem is that your ffi is not built with -fPIC for some reason that you need to figure.
Flags: needinfo?(mh+mozilla)
Comment 28•7 years ago
|
||
What does the obj-dir/js/src/ctypes/libffi/config.status file say about the value of lt_prog_compiler_pic? I'd hope that was "-fPIC -DPIC", if not need to check the config.log file to see what is happening.
Flags: needinfo?(ewong)
![]() |
Assignee | |
Comment 29•7 years ago
|
||
(In reply to Ian Neal from comment #28) > What does the obj-dir/js/src/ctypes/libffi/config.status file say about the > value of lt_prog_compiler_pic? I'd hope that was "-fPIC -DPIC", if not need > to check the config.log file to see what is happening. MAGIC_CMD='file' lt_prog_compiler_no_builtin_flag=' -fno-builtin' lt_prog_compiler_pic=' -fPIC -DPIC' lt_prog_compiler_wl='-Wl,' lt_prog_compiler_static='-static'
Flags: needinfo?(ewong)
![]() |
Assignee | |
Comment 30•7 years ago
|
||
(In reply to Edmund Wong (:ewong) from comment #29) > (In reply to Ian Neal from comment #28) > > What does the obj-dir/js/src/ctypes/libffi/config.status file say about the > > value of lt_prog_compiler_pic? I'd hope that was "-fPIC -DPIC", if not need > > to check the config.log file to see what is happening. > > MAGIC_CMD='file' > lt_prog_compiler_no_builtin_flag=' -fno-builtin' > lt_prog_compiler_pic=' -fPIC -DPIC' > lt_prog_compiler_wl='-Wl,' > lt_prog_compiler_static='-static' ^ is what we have in objdir/js/src/ctypes/libffi/config.status
Comment 31•7 years ago
|
||
Looking at the build log, you see the following line: js/src/ctypes/libffi> checking if /usr/bin/ccache /builds/slave/c-aurora-lnx-ntly/build/gcc/bin/gcc -m32 -march=pentiumpro -std=gnu99 PIC flag -fPIC -DPIC works... no Does this give a "no" on the builds that work?
Flags: needinfo?(ewong)
Comment 32•7 years ago
|
||
Saying that later in the build log, there is: js/src/ctypes/libffi> checking if /usr/bin/ccache /builds/slave/c-aurora-lnx-ntly/build/gcc/bin/g++ -m32 -march=pentiumpro -std=gnu++11 PIC flag -fPIC -DPIC works... yes So it works for g++ but not for gcc Are there any other differences for the libffi parts of the build log between working and non-working builds?
![]() |
Assignee | |
Comment 33•7 years ago
|
||
(In reply to Ian Neal from comment #32) > Saying that later in the build log, there is: > js/src/ctypes/libffi> checking if /usr/bin/ccache > /builds/slave/c-aurora-lnx-ntly/build/gcc/bin/g++ -m32 -march=pentiumpro > -std=gnu++11 PIC flag -fPIC -DPIC works... yes > > So it works for g++ but not for gcc > > Are there any other differences for the libffi parts of the build log > between working and non-working builds? Bad build: [with the -gdwarf-2 flag] js/src/ctypes/libffi> checking for /usr/bin/ccache /builds/slave/rel-c-rel-lnx-bld/build/gcc/bin/gcc -m32 -march=pentiumpro -std=gnu99 option to produce PIC... -fPIC -DPIC js/src/ctypes/libffi> checking if /usr/bin/ccache /builds/slave/rel-c-rel-lnx-bld/build/gcc/bin/gcc -m32 -march=pentiumpro -std=gnu99 PIC flag -fPIC -DPIC works... no js/src/ctypes/libffi> checking if /usr/bin/ccache /builds/slave/rel-c-rel-lnx-bld/build/gcc/bin/gcc -m32 -march=pentiumpro -std=gnu99 static flag -static works... yes Good build: [without -gdwarf-2 flag] js/src/ctypes/libffi> checking for /usr/bin/ccache /builds/slave/rel-c-rel-lnx-bld/build/gcc/bin/gcc -m32 -march=pentiumpro -std=gnu99 option to produce PIC... -fPIC -DPIC js/src/ctypes/libffi> checking if /usr/bin/ccache /builds/slave/rel-c-rel-lnx-bld/build/gcc/bin/gcc -m32 -march=pentiumpro -std=gnu99 PIC flag -fPIC -DPIC works... yes js/src/ctypes/libffi> checking if /usr/bin/ccache /builds/slave/rel-c-rel-lnx-bld/build/gcc/bin/gcc -m32 -march=pentiumpro -std=gnu99 static flag -static works... yes :glandium, I'm looking at the docs for gdwarf-2 and it's related to optimizations. does this make sense in screwing up the linking?
Status: REOPENED → ASSIGNED
Flags: needinfo?(ewong) → needinfo?(mh+mozilla)
Comment 34•7 years ago
|
||
gdwarf-2 is related to the format used for debug info. The only thing that will tell you what's going wrong is config.log.
Flags: needinfo?(mh+mozilla)
![]() |
Assignee | |
Comment 35•7 years ago
|
||
I have the following logs from objdir/js/src/ctypes/libffi : Good build: configure:9479: checking for /usr/bin/ccache /builds/slave/rel-c-rel-lnx-bld/build/gcc/bin/gcc -m32 -march=pentiumpro -std=gnu99 option to produce PIC configure:9486: result: -fPIC -DPIC configure:9494: checking if /usr/bin/ccache /builds/slave/rel-c-rel-lnx-bld/build/gcc/bin/gcc -m32 -march=pentiumpro -std=gnu99 PIC flag -fPIC -DPIC works configure:9512: /usr/bin/ccache /builds/slave/rel-c-rel-lnx-bld/build/gcc/bin/gcc -m32 -march=pentiumpro -std=gnu99 -c -fPIC -DPIC -DPIC conftest.c >&5 /builds/slave/rel-c-rel-lnx-bld/build/gcc/bin/../lib/gcc/x86_64-unknown-linux-gnu/4.8.5/../../../../x86_64-unknown-linux-gnu/bin/as: /lib64/libz.so.1: no version information available (required by /builds/slave/rel-c-rel-lnx-bld/build/gcc/bin/../lib/gcc/x86_64-unknown-linux-gnu/4.8.5/../../../../x86_64-unknown-linux-gnu/bin/as) configure:9516: $? = 0 configure:9529: result: no Bad build: configure:9479: checking for /usr/bin/ccache /builds/slave/rel-c-rel-lnx-bld/build/gcc/bin/gcc -m32 -march=pentiumpro -std=gnu99 option to produce PIC configure:9486: result: -fPIC -DPIC configure:9494: checking if /usr/bin/ccache /builds/slave/rel-c-rel-lnx-bld/build/gcc/bin/gcc -m32 -march=pentiumpro -std=gnu99 PIC flag -fPIC -DPIC works configure:9512: /usr/bin/ccache /builds/slave/rel-c-rel-lnx-bld/build/gcc/bin/gcc -m32 -march=pentiumpro -std=gnu99 -c -Wall -Wempty-body -Wignored-qualifiers -Wpointer-arith -Wsign-compare -Wtype-limits -Wunreachable-code -Wno-error=maybe-uninitialized -Wno-error=deprecated-declarations -Wno-error=array-bounds -gdwarf-2 -fno-strict-aliasing -ffunction-sections -fdata-sections -fno-math-errno -pthread -pipe -fPIC -DPIC -DPIC conftest.c >&5 /builds/slave/rel-c-rel-lnx-bld/build/gcc/bin/../lib/gcc/x86_64-unknown-linux-gnu/4.8.5/../../../../x86_64-unknown-linux-gnu/bin/as: /lib64/libz.so.1: no version information available (required by /builds/slave/rel-c-rel-lnx-bld/build/gcc/bin/../lib/gcc/x86_64-unknown-linux-gnu/4.8.5/../../../../x86_64-unknown-linux-gnu/bin/as) configure:9516: $? = 0 configure:9529: result: yes
![]() |
Assignee | |
Comment 36•7 years ago
|
||
Fixed by bug 1061348
Status: ASSIGNED → RESOLVED
Closed: 7 years ago → 7 years ago
Resolution: --- → FIXED
You need to log in
before you can comment on or make changes to this bug.
Description
•