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

Status: RESOLVED FIXED

(SeaMonkey :: Build Config, defect)

Description

[Edmund Wong (:ewong)]

/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

Comment 1

[Edmund Wong (:ewong)]

Attachment: [tooltool] proposed patch (update gcc tooltool package) [checked-in]

Comment 2

[Edmund Wong (:ewong)]

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

Comment 3

[Edmund Wong (:ewong)]

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

Comment 4

[Edmund Wong (:ewong)]

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.

Comment 5

[Edmund Wong (:ewong)]

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

Comment 6

[Edmund Wong (:ewong)]

(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

Comment 7

[Edmund Wong (:ewong)]

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

Comment 8

[Edmund Wong (:ewong)]

Seems like the patch unhorked the c-a build...  nice!

Comment 10

[Edmund Wong (:ewong)]

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

Comment 11

[Philip Chee]

Comment on attachment 8779611 [details] [diff] [review]
[tooltool] proposed patch (update gcc tooltool package) [checked-in]

rs=me

Comment 12

[Edmund Wong (:ewong)]

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

Comment 13

[Edmund Wong (:ewong)]

was wrong.. apparently this isn't fixed.

Comment 14

[Edmund Wong (:ewong)]

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

Comment 15

[Edmund Wong (:ewong)]

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

Comment 16

[Edmund Wong (:ewong)]

Attachment: build.log

Build log

Comment 17

[Edmund Wong (:ewong)]

Attachment: mozconfig used (suite/config/mozconfigs/linux32/nightly)

Comment 18

[Edmund Wong (:ewong)]

https://hg.mozilla.org/SeaMonkey/puppet/rev/d48761db4d181d55cdcb5c8ee5b20ff71323df72
Whitelist c-aurora-lnx-ntly to figure out Bug 1293928

Comment 19

[Edmund Wong (:ewong)]

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

[Jorg K (CEST = GMT+2)]

What's happening to ewong: approval-comm-beta+ ?
Is this ever going to land on any beta or can this be cleared?

Comment 21

[Edmund Wong (:ewong)]

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

Comment 22

[Jorg K (CEST = GMT+2)]

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

Comment 23

[Edmund Wong (:ewong)]

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.

Comment 24

[Edmund Wong (:ewong)]

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.

Comment 25

[Edmund Wong (:ewong)]

Attachment: linking log

Comment 26

[Edmund Wong (:ewong)]

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?

Comment 27

[Mike Hommey [:glandium]]

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.

Comment 28

[Ian Neal]

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.

Comment 29

[Edmund Wong (:ewong)]

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

Comment 30

[Edmund Wong (:ewong)]

(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

[Ian Neal]

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?

Comment 32

[Ian Neal]

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?

Comment 33

[Edmund Wong (:ewong)]

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

Comment 34

[Mike Hommey [:glandium]]

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.

Comment 35

[Edmund Wong (:ewong)]

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

Comment 36

[Edmund Wong (:ewong)]

Fixed by bug 1061348