binutils upgrade to 2.26 failure - unsupported reloc 42 against global symbol __gmon_start__

DISCUSSION Trevor Woerner 6 participants 13 messages Feb 3, 2016 – Feb 4, 2016

lore

Share & tools

lore

Khem Raj

2016-02-03 19:56 UTC #1 lore raw

Quoted 13 lines · Trevor Woerner

My chromium build is now failing due to:

commit 86ade2cc2553c942d9526c5323a11ae151653505
binutils: Upgrade to 2.26

| FAILED: x86_64-oe-linux-gcc  -m64 -march=corei7 -mtune=corei7 -mfpmath=sse -msse4.2 --sysroot=/z/chromium-49/build/tmp-glibc/sysroots/intel-corei7-64 -Wl,-O1 -Wl,--hash-style=gnu -Wl,--as-needed -Wl,-z,now -Wl,-z,relro -Wl,-z,defs -pthread -Wl,-z,noexecstack -fPIC -B/z/chromium-49/build/tmp-glibc/work/corei7-64-oe-linux/chromium/49.0.2612.0-r0/chromium-49.0.2612.0/third_party/binutils/Linux_x64/Release/bin -Wl,--disable-new-dtags -m64 -Wl,-O1 -Wl,--as-needed -Wl,--gc-sections -o chrome_sandbox -Wl,--start-group obj/sandbox/linux/suid/chrome_sandbox.process_util_linux.o obj/sandbox/linux/suid/chrome_sandbox.sandbox.o -Wl,--end-group
| /z/chromium-49/build/tmp-glibc/work/corei7-64-oe-linux/chromium/49.0.2612.0-r0/chromium-49.0.2612.0/third_party/binutils/Linux_x64/Release/bin/ld: error: /z/chromium-49/build/tmp-glibc/sysroots/intel-corei7-64/usr/lib/../lib/crti.o: unsupported reloc 42 against global symbol __gmon_start__
| ../sysdeps/x86_64/crti.S:66: error: unsupported reloc 42

Any suggestions on how to approach this?

do a clean build. Its mixing objects

Quoted 5 lines

--
_______________________________________________
Openembedded-core mailing list
[email protected]
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Paul Eggleton

2016-02-03 20:09 UTC #2 lore raw

Quoted 25 lines · On Wed, 03 Feb 2016 11:56:45 Khem Raj wrote:

Quoted 25 lines · Trevor Woerner

My chromium build is now failing due to:
commit 86ade2cc2553c942d9526c5323a11ae151653505

binutils: Upgrade to 2.26

| 
| FAILED: x86_64-oe-linux-gcc  -m64 -march=corei7 -mtune=corei7
| -mfpmath=sse -msse4.2
| --sysroot=/z/chromium-49/build/tmp-glibc/sysroots/intel-corei7-64
| -Wl,-O1 -Wl,--hash-style=gnu -Wl,--as-needed -Wl,-z,now -Wl,-z,relro
| -Wl,-z,defs -pthread -Wl,-z,noexecstack -fPIC
| -B/z/chromium-49/build/tmp-glibc/work/corei7-64-oe-linux/chromium/49.0.
| 2612.0-r0/chromium-49.0.2612.0/third_party/binutils/Linux_x64/Release/bi
| n -Wl,--disable-new-dtags -m64 -Wl,-O1 -Wl,--as-needed -Wl,--gc-sections
| -o chrome_sandbox -Wl,--start-group
| obj/sandbox/linux/suid/chrome_sandbox.process_util_linux.o
| obj/sandbox/linux/suid/chrome_sandbox.sandbox.o -Wl,--end-group
| /z/chromium-49/build/tmp-glibc/work/corei7-64-oe-linux/chromium/49.0.26
| 12.0-r0/chromium-49.0.2612.0/third_party/binutils/Linux_x64/Release/bin/
| ld: error:
| /z/chromium-49/build/tmp-glibc/sysroots/intel-corei7-64/usr/lib/../lib/
| crti.o: unsupported reloc 42 against global symbol __gmon_start__
| ../sysdeps/x86_64/crti.S:66: error: unsupported reloc 42

Quoted 3 lines

Quoted 1 line
Any suggestions on how to approach this?
do a clean build. Its mixing objects

Should we have bumped PR somewhere to avoid this?

Cheers,
Paul

Signature · 2 lines

Paul Eggleton
Intel Open Source Technology Centre

Khem Raj

2016-02-03 20:21 UTC #3 lore raw

Quoted 29 lines · Paul Eggleton

Quoted 25 lines · On Wed, 03 Feb 2016 11:56:45 Khem Raj wrote:

Quoted 25 lines · Trevor Woerner

My chromium build is now failing due to:
commit 86ade2cc2553c942d9526c5323a11ae151653505

binutils: Upgrade to 2.26

|
| FAILED: x86_64-oe-linux-gcc  -m64 -march=corei7 -mtune=corei7
| -mfpmath=sse -msse4.2
| --sysroot=/z/chromium-49/build/tmp-glibc/sysroots/intel-corei7-64
| -Wl,-O1 -Wl,--hash-style=gnu -Wl,--as-needed -Wl,-z,now -Wl,-z,relro
| -Wl,-z,defs -pthread -Wl,-z,noexecstack -fPIC
| -B/z/chromium-49/build/tmp-glibc/work/corei7-64-oe-linux/chromium/49.0.
| 2612.0-r0/chromium-49.0.2612.0/third_party/binutils/Linux_x64/Release/bi
| n -Wl,--disable-new-dtags -m64 -Wl,-O1 -Wl,--as-needed -Wl,--gc-sections
| -o chrome_sandbox -Wl,--start-group
| obj/sandbox/linux/suid/chrome_sandbox.process_util_linux.o
| obj/sandbox/linux/suid/chrome_sandbox.sandbox.o -Wl,--end-group
| /z/chromium-49/build/tmp-glibc/work/corei7-64-oe-linux/chromium/49.0.26
| 12.0-r0/chromium-49.0.2612.0/third_party/binutils/Linux_x64/Release/bin/
| ld: error:
| /z/chromium-49/build/tmp-glibc/sysroots/intel-corei7-64/usr/lib/../lib/
| crti.o: unsupported reloc 42 against global symbol __gmon_start__
| ../sysdeps/x86_64/crti.S:66: error: unsupported reloc 42

Quoted 5 lines

Quoted 3 lines
Quoted 1 line
Any suggestions on how to approach this?
do a clean build. Its mixing objects
Should we have bumped PR somewhere to avoid this?

Don’t think so. this could happen due to new relocs appearing in glibc due to the fact thats its now compiled with newer binutils but we are still using old linker to link the app which does not understand these relocations. Why would that happen don’t know.

Quoted 8 lines

Cheers,
Paul
--
Paul Eggleton
Intel Open Source Technology Centre

Trevor Woerner

author

2016-02-03 20:27 UTC #12 lore raw

In reply to Khem Raj

Quoted 7 lines · Khem Raj

Quoted 7 lines · Trevor Woerner
My chromium build is now failing due to:
commit 86ade2cc2553c942d9526c5323a11ae151653505
binutils: Upgrade to 2.26

Quoted 6 lines

Quoted 5 lines

| FAILED: x86_64-oe-linux-gcc  -m64 -march=corei7 -mtune=corei7 -mfpmath=sse -msse4.2 --sysroot=/z/chromium-49/build/tmp-glibc/sysroots/intel-corei7-64 -Wl,-O1 -Wl,--hash-style=gnu -Wl,--as-needed -Wl,-z,now -Wl,-z,relro -Wl,-z,defs -pthread -Wl,-z,noexecstack -fPIC -B/z/chromium-49/build/tmp-glibc/work/corei7-64-oe-linux/chromium/49.0.2612.0-r0/chromium-49.0.2612.0/third_party/binutils/Linux_x64/Release/bin -Wl,--disable-new-dtags -m64 -Wl,-O1 -Wl,--as-needed -Wl,--gc-sections -o chrome_sandbox -Wl,--start-group obj/sandbox/linux/suid/chrome_sandbox.process_util_linux.o obj/sandbox/linux/suid/chrome_sandbox.sandbox.o -Wl,--end-group
| /z/chromium-49/build/tmp-glibc/work/corei7-64-oe-linux/chromium/49.0.2612.0-r0/chromium-49.0.2612.0/third_party/binutils/Linux_x64/Release/bin/ld: error: /z/chromium-49/build/tmp-glibc/sysroots/intel-corei7-64/usr/lib/../lib/crti.o: unsupported reloc 42 against global symbol __gmon_start__
| ../sysdeps/x86_64/crti.S:66: error: unsupported reloc 42

Any suggestions on how to approach this?

do a clean build. Its mixing objects

Unfortunately this *is* with completely clean builds; I'm deleting everything except conf/ before each try. I just finished testing with ld-is-gold and it fails too in exactly the same way.

I'll make stuff available for you to test after I try a build with 50.0.2636.0

Martin Jansa

2016-02-03 20:32 UTC #4 lore raw

In reply to Khem Raj

This could be caused by chromium using own bundled binutils where the version doesn't match, I've solved it in our recipe by:
+GYP_DEFINES_append = " linux_use_bundled_gold=0" +GYP_DEFINES_append = " linux_use_bundled_binutils=0"

In my cases it was failing while building native libvpx (also bundled in chromium sources) when I've upgraded host binutils to
(GNU gold (GNU Binutils for Ubuntu 2.25.90.20160101) 1.11) included in Ubuntu-16.04 Alpha

Quoted 68 lines · Khem Raj

Quoted 2 lines
On Feb 3, 2016, at 12:09 PM, Paul Eggleton <
Quoted 3 lines · [email protected]> wrote:
Quoted 1 line · On Wed, 03 Feb 2016 11:56:45 Khem Raj wrote:
Quoted 1 line
On Feb 3, 2016, at 11:29 AM, Trevor Woerner <[email protected]>
Quoted 4 lines · wrote:
Quoted 4 lines
Quoted 4 lines
My chromium build is now failing due to:
commit 86ade2cc2553c942d9526c5323a11ae151653505
Quoted 8 lines
Quoted 8 lines
Quoted 8 lines
binutils: Upgrade to 2.26
|
| FAILED: x86_64-oe-linux-gcc  -m64 -march=corei7 -mtune=corei7
| -mfpmath=sse -msse4.2
| --sysroot=/z/chromium-49/build/tmp-glibc/sysroots/intel-corei7-64
| -Wl,-O1 -Wl,--hash-style=gnu -Wl,--as-needed -Wl,-z,now -Wl,-z,relro
| -Wl,-z,defs -pthread -Wl,-z,noexecstack -fPIC
|
-B/z/chromium-49/build/tmp-glibc/work/corei7-64-oe-linux/chromium/49.0.
Quoted 1 line
Quoted 1 line
Quoted 1 line
|
2612.0-r0/chromium-49.0.2612.0/third_party/binutils/Linux_x64/Release/bi
Quoted 1 line
Quoted 1 line
Quoted 1 line
| n -Wl,--disable-new-dtags -m64 -Wl,-O1 -Wl,--as-needed
-Wl,--gc-sections
Quoted 4 lines
Quoted 4 lines
Quoted 4 lines
| -o chrome_sandbox -Wl,--start-group
| obj/sandbox/linux/suid/chrome_sandbox.process_util_linux.o
| obj/sandbox/linux/suid/chrome_sandbox.sandbox.o -Wl,--end-group
|
/z/chromium-49/build/tmp-glibc/work/corei7-64-oe-linux/chromium/49.0.26
Quoted 1 line
Quoted 1 line
Quoted 1 line
|
12.0-r0/chromium-49.0.2612.0/third_party/binutils/Linux_x64/Release/bin/
Quoted 2 lines
Quoted 2 lines
Quoted 2 lines
| ld: error:
|
/z/chromium-49/build/tmp-glibc/sysroots/intel-corei7-64/usr/lib/../lib/
Quoted 8 lines
Quoted 6 lines
Quoted 4 lines
| crti.o: unsupported reloc 42 against global symbol __gmon_start__ | ../sysdeps/x86_64/crti.S:66: error: unsupported reloc 42
Any suggestions on how to approach this?
do a clean build. Its mixing objects
Should we have bumped PR somewhere to avoid this?
Don’t think so. this could happen due to new relocs appearing in glibc due to the fact
thats its now compiled with newer binutils but we are still using old linker
to link the app which does not understand these relocations. Why would that happen
don’t know.
Quoted 8 lines
Cheers,
Paul
--
Paul Eggleton
Intel Open Source Technology Centre
--
_______________________________________________
Openembedded-core mailing list
[email protected]
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Khem Raj

2016-02-03 20:51 UTC #5 lore raw

Review

Quoted 5 lines · Martin Jansa

This could be caused by chromium using own bundled binutils where the version doesn't match, I've solved it in our recipe by:
(quoted diff) +2 -0
+GYP_DEFINES_append = " linux_use_bundled_gold=0"
+GYP_DEFINES_append = " linux_use_bundled_binutils=0"

there we go. chromium has world of its own but then they should really insulate themselves.

Quoted 77 lines

In my cases it was failing while building native libvpx (also bundled in chromium sources) when I've upgraded host binutils to
(GNU gold (GNU Binutils for Ubuntu 2.25.90.20160101) 1.11) included in Ubuntu-16.04 Alpha
Quoted 68 lines · Khem Raj
Quoted 38 lines
On Feb 3, 2016, at 12:09 PM, Paul Eggleton
<[email protected]> wrote:
Quoted 32 lines · On Wed, 03 Feb 2016 11:56:45 Khem Raj wrote:
Quoted 32 lines
On Feb 3, 2016, at 11:29 AM, Trevor Woerner <[email protected]> wrote:
My chromium build is now failing due to:
commit 86ade2cc2553c942d9526c5323a11ae151653505
binutils: Upgrade to 2.26
|
| FAILED: x86_64-oe-linux-gcc  -m64 -march=corei7 -mtune=corei7
| -mfpmath=sse -msse4.2
| --sysroot=/z/chromium-49/build/tmp-glibc/sysroots/intel-corei7-64
| -Wl,-O1 -Wl,--hash-style=gnu -Wl,--as-needed -Wl,-z,now -Wl,-z,relro
| -Wl,-z,defs -pthread -Wl,-z,noexecstack -fPIC
|
-B/z/chromium-49/build/tmp-glibc/work/corei7-64-oe-linux/chromium/49.0. | 2612.0-r0/chromium-49.0.2612.0/third_party/binutils/Linux_x64/Release/bi | n -Wl,--disable-new-dtags -m64 -Wl,-O1 -Wl,--as-needed -Wl,--gc-sections
| -o chrome_sandbox -Wl,--start-group
| obj/sandbox/linux/suid/chrome_sandbox.process_util_linux.o
| obj/sandbox/linux/suid/chrome_sandbox.sandbox.o -Wl,--end-group
|
/z/chromium-49/build/tmp-glibc/work/corei7-64-oe-linux/chromium/49.0.26 | 12.0-r0/chromium-49.0.2612.0/third_party/binutils/Linux_x64/Release/bin/ | ld: error:
| /z/chromium-49/build/tmp-glibc/sysroots/intel-corei7-64/usr/lib/../lib/ | crti.o: unsupported reloc 42 against global symbol __gmon_start__ | ../sysdeps/x86_64/crti.S:66: error: unsupported reloc 42
Quoted 5 lines
Quoted 3 lines
Quoted 1 line
Any suggestions on how to approach this?
do a clean build. Its mixing objects
Should we have bumped PR somewhere to avoid this?
Don’t think so. this could happen due to new relocs appearing in glibc due to the fact
thats its now compiled with newer binutils but we are still using old linker
to link the app which does not understand these relocations. Why would that happen
don’t know.
Quoted 8 lines
Cheers,
Paul
--
Paul Eggleton
Intel Open Source Technology Centre
--
_______________________________________________
Openembedded-core mailing list
[email protected]
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Burton, Ross

2016-02-03 20:55 UTC #6 lore raw

In reply to Martin Jansa

Quoted 1 line · Martin Jansa

This could be caused by chromium using own bundled binutils

Wait, WHAT?! :O

Trevor Woerner

author

2016-02-04 03:06 UTC #7 lore raw

In reply to Martin Jansa

Review

Quoted 3 lines · Martin Jansa

This could be caused by chromium using own bundled binutils where the version doesn't match, I've solved it in our recipe by:
(quoted diff) +2 -0
+GYP_DEFINES_append = " linux_use_bundled_gold=0"
+GYP_DEFINES_append = " linux_use_bundled_binutils=0"

w00t!! awesome. works for me :-)

So it looks like we both have working chromium recipes, yet the upstream one doesn't work. What version are you building? For what arch (which archs)? x11/wayland?

I have a working recipe for 50.0.2636.0, but I'm only interested in x86_64 and x11. wayland+ozone is a whole other mess ;-)

At some point it'll probably be easier if we build chromium with llvm-clang, the same as google is doing. Is that possible?

Khem Raj

2016-02-04 03:08 UTC #8 lore raw

Quoted 11 lines · Trevor Woerner

Review
Quoted 3 lines · Martin Jansa
This could be caused by chromium using own bundled binutils where the version doesn't match, I've solved it in our recipe by:
(quoted diff) +2 -0
+GYP_DEFINES_append = " linux_use_bundled_gold=0"
+GYP_DEFINES_append = " linux_use_bundled_binutils=0"
w00t!! awesome. works for me :-)
So it looks like we both have working chromium recipes, yet the upstream one doesn't work. What version are you building? For what arch (which archs)? x11/wayland?

please submit your patch for meta-browser

Quoted 4 lines

I have a working recipe for 50.0.2636.0, but I'm only interested in x86_64 and x11. wayland+ozone is a whole other mess ;-)
At some point it'll probably be easier if we build chromium with llvm-clang, the same as google is doing. Is that possible?

you can try using meta-clang

Quoted 5 lines

--
_______________________________________________
Openembedded-core mailing list
[email protected]
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Trevor Woerner

author

2016-02-04 03:30 UTC #9 lore raw

Quoted 10 lines · Khem Raj

Quoted 10 lines · Trevor Woerner
Review
Quoted 3 lines · Martin Jansa
This could be caused by chromium using own bundled binutils where the version doesn't match, I've solved it in our recipe by:
(quoted diff) +2 -0
+GYP_DEFINES_append = " linux_use_bundled_gold=0"
+GYP_DEFINES_append = " linux_use_bundled_binutils=0"
w00t!! awesome. works for me :-)

Quoted 3 lines

Quoted 1 line
So it looks like we both have working chromium recipes, yet the upstream one doesn't work. What version are you building? For what arch (which archs)? x11/wayland?
please submit your patch for meta-browser

Any patch I submit is guaranteed to be rejected. It only supports x11 and has only been tested on x86_64. If nothing else it would have to be named chromium-x11_<version>.bb, or something like that. I've actually removed the wayland/ozone stuff from my recipe.

Considering each build of chromium takes me 2.5 hours (just for chromium alone!) it makes it hard to care about environments I'm not using.

The only way chromium builds for wayland is when another project (ozone) is added to the mix. But, in my tests so far, not every release of chromium builds successfully with every version of ozone. So although building for x11 is easy and works for just about each release, building for wayland is much more hit-and-miss (and has less chance of success).

Quoted 6 lines

Quoted 4 lines
I have a working recipe for 50.0.2636.0, but I'm only interested in x86_64 and x11. wayland+ozone is a whole other mess ;-)
At some point it'll probably be easier if we build chromium with llvm-clang, the same as google is doing. Is that possible?
you can try using meta-clang

Okay. So if I have an image and everything in that image is built with gcc except for chromium, meta-clang will know what it needs to add to the image so that one clang-built package can run?

Dan McGregor

2016-02-04 03:46 UTC #10 lore raw

Quoted 9 lines · Trevor Woerner

Quoted 7 lines · Khem Raj
Quoted 7 lines · Trevor Woerner
Quoted 2 lines · Martin Jansa
This could be caused by chromium using own bundled binutils where the

version doesn't match, I've solved it in our recipe by:

Quoted 7 lines

Quoted 7 lines
Quoted 7 lines
Review
Quoted 2 lines
(quoted diff) +2 -0
+GYP_DEFINES_append = " linux_use_bundled_gold=0"
+GYP_DEFINES_append = " linux_use_bundled_binutils=0"
w00t!! awesome. works for me :-)
So it looks like we both have working chromium recipes, yet the

upstream one doesn't work. What version are you building? For what arch (which archs)? x11/wayland?

Quoted 6 lines

Quoted 3 lines
please submit your patch for meta-browser
Any patch I submit is guaranteed to be rejected. It only supports x11 and

has only been tested on x86_64. If nothing else it would have to be named chromium-x11_<version>.bb, or something like that. I've actually removed the wayland/ozone stuff from my recipe.

Quoted 2 lines

Considering each build of chromium takes me 2.5 hours (just for chromium

alone!) it makes it hard to care about environments I'm not using.

Quoted 2 lines

The only way chromium builds for wayland is when another project (ozone)

is added to the mix. But, in my tests so far, not every release of chromium builds successfully with every version of ozone. So although building for x11 is easy and works for just about each release, building for wayland is much more hit-and-miss (and has less chance of success).

Quoted 4 lines

Quoted 4 lines
Quoted 4 lines
I have a working recipe for 50.0.2636.0, but I'm only interested in

x86_64 and x11. wayland+ozone is a whole other mess ;-)

Quoted 2 lines

Quoted 2 lines
Quoted 2 lines
At some point it'll probably be easier if we build chromium with

llvm-clang, the same as google is doing. Is that possible?

Quoted 6 lines

Quoted 3 lines
you can try using meta-clang
Okay. So if I have an image and everything in that image is built with

gcc except for chromium, meta-clang will know what it needs to add to the image so that one clang-built package can run?

Quoted 1 line

Clang built packages and GCC built packages should have the same run time dependencies. You'd have to go out of your way to build against LLVM's unwinder or c++ runtime.

Quoted 5 lines

--
_______________________________________________
Openembedded-core mailing list
[email protected]
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Khem Raj

2016-02-04 04:24 UTC #11 lore raw

In reply to Trevor Woerner

Quoted 25 lines · Trevor Woerner

Quoted 10 lines · Khem Raj
Quoted 10 lines · Trevor Woerner
Review
Quoted 3 lines · Martin Jansa
This could be caused by chromium using own bundled binutils where the version doesn't match, I've solved it in our recipe by:
(quoted diff) +2 -0
+GYP_DEFINES_append = " linux_use_bundled_gold=0"
+GYP_DEFINES_append = " linux_use_bundled_binutils=0"
w00t!! awesome. works for me :-)
Quoted 3 lines
Quoted 1 line
So it looks like we both have working chromium recipes, yet the upstream one doesn't work. What version are you building? For what arch (which archs)? x11/wayland?
please submit your patch for meta-browser
Any patch I submit is guaranteed to be rejected. It only supports x11 and has only been tested on x86_64. If nothing else it would have to be named chromium-x11_<version>.bb, or something like that. I've actually removed the wayland/ozone stuff from my recipe.
Considering each build of chromium takes me 2.5 hours (just for chromium alone!) it makes it hard to care about environments I'm not using.
The only way chromium builds for wayland is when another project (ozone) is added to the mix. But, in my tests so far, not every release of chromium builds successfully with every version of ozone. So although building for x11 is easy and works for just about each release, building for wayland is much more hit-and-miss (and has less chance of success).
Quoted 1 line
Quoted 1 line

Quoted 7 lines

Quoted 5 lines
Quoted 3 lines
I have a working recipe for 50.0.2636.0, but I'm only interested in x86_64 and x11. wayland+ozone is a whole other mess ;-)
At some point it'll probably be easier if we build chromium with llvm-clang, the same as google is doing. Is that possible?
you can try using meta-clang
Okay. So if I have an image and everything in that image is built with gcc except for chromium, meta-clang will know what it needs to add to the image so that one clang-built package can run?

actually it will make clang as default compiler and there are some stubborn recipes which are hardcoded to use gcc even when clang is available see see https://github.com/kraj/meta-clang/tree/master/recipes-excluded/nonclangable

you just need to set

TOOLCHAIN = “gcc"

Quoted 5 lines

--
_______________________________________________
Openembedded-core mailing list
[email protected]
http://lists.openembedded.org/mailman/listinfo/openembedded-core