Linux* nightly busted with bin/ld: read-only segment has dynamic relocations.

RESOLVED FIXED in seamonkey2.46

Status

defect
RESOLVED FIXED
3 years ago
3 years ago

People

(Reporter: ewong, Assigned: ewong)

Tracking

unspecified
seamonkey2.46
Dependency tree / graph

SeaMonkey Tracking Flags

(seamonkey2.45 fixed, seamonkey2.46 fixed, seamonkey2.47 fixed, seamonkey2.48 affected)

Details

Attachments

(4 attachments)

Assignee

Description

3 years ago
/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

3 years ago
Assignee: nobody → ewong
Status: NEW → ASSIGNED
Attachment #8779611 - Flags: review?(philip.chee)
Assignee

Comment 2

3 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

3 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

3 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

3 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

3 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

3 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

3 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

3 years ago
Attachment #8779611 - Flags: approval-comm-aurora? → approval-comm-aurora+
Assignee

Comment 8

3 years ago
Seems like the patch unhorked the c-a build...  nice!
Assignee

Updated

3 years ago
Duplicate of this bug: 1295399
Assignee

Comment 10

3 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

3 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

3 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

3 years ago
Status: ASSIGNED → RESOLVED
Closed: 3 years ago
Resolution: --- → FIXED
Target Milestone: --- → seamonkey2.46
Assignee

Comment 13

3 years ago
was wrong.. apparently this isn't fixed.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Assignee

Updated

3 years ago
Status: REOPENED → ASSIGNED
Assignee

Comment 14

3 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

3 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

3 years ago
Posted file build.log
Build log

Comment 20

3 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

3 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: 3 years ago3 years ago
Flags: needinfo?(ewong)
Resolution: --- → FIXED

Comment 22

3 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

3 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

3 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

3 years ago
Posted file linking log
Attachment #8796485 - Attachment mime type: text/x-log → text/plain
Assignee

Updated

3 years ago
Blocks: SM2.46
Assignee

Comment 26

3 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)
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

3 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

3 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

3 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

3 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

3 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

3 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)
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

3 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

3 years ago
Fixed by bug 1061348
Status: ASSIGNED → RESOLVED
Closed: 3 years ago3 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.