Bug 663442 – www-client/chromium-69.0.3497.32 ld: obj/third_party/swift shader/src/OpenGL/libGLESv2/swiftshader_libGLESv2_static/libGLESv2.o: relocation R_X86_64_PC32 again st protected symbol `glBlendEquationSeparate' can not be used when making a shared object

• Status: RESOLVED FIXED
• Product: Gentoo Linux

[Description Mike Gilbert 2018-08-12 14:04:10 UTC]

This error occurs with binutils-2.31.1, but not with binutils-2.30.0.

FAILED: swiftshader/libGLESv2.so swiftshader/libGLESv2.so.TOC
python "../../build/toolchain/gcc_solink_wrapper.py" --readelf="readelf" --nm="x86_64-pc-linux-gnu-n
m" --sofile="swiftshader/libGLESv2.so" --tocfile="swiftshader/libGLESv2.so.TOC" --output="swiftshade
r/libGLESv2.so"  -- x86_64-pc-linux-gnu-clang++ -shared -Wl,--version-script=../../third_party/swift
shader/src/OpenGL/libGLESv2/libGLESv2.lds -fPIC -Wl,-z,noexecstack -Wl,-z,now -Wl,-z,relro -Wl,-z,de
fs -Wl,--as-needed -rdynamic -Wl,--hash-style=both -Wl,--gc-sections -Wl,-O1 -Wl,--as-needed -o "swi
ftshader/libGLESv2.so" -Wl,-soname="libGLESv2.so" @"swiftshader/libGLESv2.so.rsp"
/usr/lib/gcc/x86_64-pc-linux-gnu/7.3.0/../../../../x86_64-pc-linux-gnu/bin/ld: obj/third_party/swift
shader/src/OpenGL/libGLESv2/swiftshader_libGLESv2_static/libGLESv2.o: relocation R_X86_64_PC32 again
st protected symbol `glBlendEquationSeparate' can not be used when making a shared object
/usr/lib/gcc/x86_64-pc-linux-gnu/7.3.0/../../../../x86_64-pc-linux-gnu/bin/ld: final link failed: ba
d value
clang-6.0: error: linker command failed with exit code 1 (use -v to see invocation)

[Comment 1 Mike Gilbert 2018-08-12 14:05:17 UTC]

@toolchain: Any idea what is happening here?

[Comment 2 Sergei Trofimovich (RETIRED) 2018-08-12 22:37:43 UTC]

Reproduced it locally. I'll try to poke more to get better understanding of the failure.

[Comment 3 Sergei Trofimovich (RETIRED) 2018-08-14 20:59:06 UTC]

Confirmed it's a binutils-2.30 -> binutils-2.31.1 change.
Minimal(ish) reproducer is:

$ /tmp/portage/www-client/chromium-69.0.3497.32/work/chromium-69.0.3497.32/out/Release:LANG=C g++ -shared -Wl,--version-script=../../third_party/swiftshader/src/OpenGL/libGLESv2/libGLESv2.lds -fPIC -o swiftshader/libGLESv2.so obj/third_party/swiftshader/src/OpenGL/libGLESv2/swiftshader_libGLESv2/entry_points.o obj/third_party/swiftshader/src/OpenGL/libGLESv2/libswiftshader_libGLESv2_static.a

/usr/lib/gcc/x86_64-pc-linux-gnu/8.1.0/../../../../x86_64-pc-linux-gnu/bin/ld: obj/third_party/swiftshader/src/OpenGL/libGLESv2/swiftshader_libGLESv2_static/libGLESv2.o: relocation R_X86_64_PC32 against protected symbol `glBlendEquationSeparate' can not be used when making a shared object
/usr/lib/gcc/x86_64-pc-linux-gnu/8.1.0/../../../../x86_64-pc-linux-gnu/bin/ld: final link failed: bad value
collect2: error: ld returned 1 exit status

Will shrink it down to something for upstream to decide if it's a bug or a feature that catches a real problem of __attribute__((visibility("hidden"))) symbol to be re-exposed as global via linker script.

[Comment 4 Sergei Trofimovich (RETIRED) 2018-08-14 22:23:48 UTC]

Filed https://sourceware.org/PR23527 upstream.

[Comment 5 Sergei Trofimovich (RETIRED) 2018-08-15 15:25:38 UTC]

(In reply to Sergei Trofimovich from comment #4)
> Filed https://sourceware.org/PR23527 upstream.

H.J.++ clarified it was intentional change in ld to restrict R_X86_64_PC32 to non-shared objects. Gentoo's llvm-as will need to adapt to the change as well.

llvm-HEAD (and llvm-7) already did:
    https://reviews.llvm.org/D43383

https://sourceware.org/bugzilla/show_bug.cgi?id=23527#c4

[Comment 6 Mike Gilbert 2018-08-15 15:53:07 UTC]

@llvm: Could we get this change backported to clang/llvm 6?

[Comment 7 Michał Górny 2018-08-15 16:12:51 UTC]

Created attachment 543516 [details, diff]
0001-llvm-mc-Produce-R_X86_64_PLT32-for-call-jmp-foo.patch

I suppose so.  I've rebased the commit on release_60 branch.  Could you please rebuild 6.0.1 with the attached patch and let me know whether it fixes the issue for you?

[Comment 8 Mike Gilbert 2018-08-16 02:41:29 UTC]

To what package should this patch be applied? I tried rebuilding sys-devel/llvm, and it made no difference.

[Comment 9 Michał Górny 2018-08-16 03:48:29 UTC]

The linked differential only included stuff for LLVM.  Maybe there's a clang followup which wasn't linked here.

[Comment 10 Dan Goodliffe 2018-08-16 09:18:10 UTC]

I applied the patch to LLVM. Attempted build of Chromium failed, no change... but I think there was a lot of CCache hits involved.
I then rebuilt Clang (no patches, just a rebuild) and attempted build of Chromium succeeded and works.
Not sure if the Clang rebuild is required to fix it or if that just invalidate the CCache cache.

[Comment 11 Sergei Trofimovich (RETIRED) 2018-08-16 13:19:45 UTC]

(In reply to Dan Goodliffe from comment #10)
> I applied the patch to LLVM. Attempted build of Chromium failed, no
> change... but I think there was a lot of CCache hits involved.
> I then rebuilt Clang (no patches, just a rebuild) and attempted build of
> Chromium succeeded and works.
> Not sure if the Clang rebuild is required to fix it or if that just
> invalidate the CCache cache.

You will need to invalidate ccache cache, yes. By default ccache does not recompile the sources if compiler's executable did not change. Rebuilding clang happens to change clang's binary timestamp (maybe contents as well) and effectively invalidates all caches.

See 'compiler_check' https://ccache.samba.org/manual.html#_configuration. You could also use CCACHE_RECACHE to retain rest of cache.

I've applied
    0001-llvm-mc-Produce-R_X86_64_PLT32-for-call-jmp-foo.patch
locally to llvm:6 and it made chromium compile for me (failed before).

If it still fails with a similar error for anyone please attach a build.log / emerge --info and we'll try to investigate.

[Comment 12 Mike Gilbert 2018-08-16 17:45:12 UTC]

My failure was also due to ccache. Building chromium with CCACHE_RECACHE=true was successful.

[Comment 13 Michał Górny 2018-08-16 17:50:35 UTC]

Thanks, y'all.  I'm rebuilding LLVM with the patch myself right now, and when the tests finish, I'll push the revbump with the patch.

[Comment 14 Larry the Git Cow 2018-08-16 18:49:27 UTC]

The bug has been closed via the following commit(s):

https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=d4850f51bb1610a9c16ee5d6da6515e6aefff8f9

commit d4850f51bb1610a9c16ee5d6da6515e6aefff8f9
Author:     Michał Górny <[e-mail]>
AuthorDate: 2018-08-16 17:52:17 +0000
Commit:     Michał Górny <[e-mail]>
CommitDate: 2018-08-16 18:49:20 +0000

    sys-devel/llvm: Backport binutils compatibility patch to 6.0.1
    
    Backport the patch necessary to make LLVM assembly compatible
    with new restrictions in binutils-2.31.1.
    
    Closes: https://bugs.gentoo.org/663442

 ...c-Produce-R_X86_64_PLT32-for-call-jmp-foo.patch | 314 +++++++++++++++++++++
 sys-devel/llvm/llvm-6.0.1-r1.ebuild                | 266 +++++++++++++++++
 2 files changed, 580 insertions(+)

[Comment 15 tt_1 2018-08-19 18:49:39 UTC]

I just wanted to merge llvm-6.0.1-r1 as a precaution, before upgrading my system to binutils-2.31.1 - is this patch supposed to break llvm when there is still the older binutils-2.30 installed and active? Looks like this:  

In file included from /var/tmp/portage/sys-devel/llvm-6.0.1-r1/work/llvm-6.0.1.src/lib/Target/X86/MCTargetDesc/X86MCTargetDesc.cpp:43:0:
lib/Target/X86/X86GenSubtargetInfo.inc:21037:35: internal compiler error: in cpp_interpret_string_1, at libcpp/charset.c:1613
   {DBGFIELD("VPSRAWri")           1, false, false, 314, 4,  2, 1,  0, 0}, // #687
                                   ^

[Comment 16 tt_1 2018-09-06 10:45:57 UTC]

Tried to tackle this today, but I can't reproduce my failed compile from four weeks anymore despite using the same older binutils-2.30

[Comment 17 Mike Gilbert 2018-10-15 19:55:50 UTC]

*** Bug 668648 has been marked as a duplicate of this bug. ***