Hi Stafford,
Le 23/08/2019 à 15:47, Stafford Horne a écrit :
On Fri, Aug 16, 2019 at 07:35:33PM +0200, Romain Naour
wrote:
Hi Waldemar,
I discovered an issue with uClibc and binutils 2.32 and gcc 9.1 or 9.2.
Hi Romain,
Thank you for reporting and doing the initial investigation. Sorry, I haven't
built uclibc-ng for a while.
You're welcome, your help is very appreciated.
Have you been able to make much progress?
Yes and no...
LD libuClibc-1.0.31.so
/opt/openrisc--uclibc--bleeding-edge-1/lib/gcc/or1k-buildroot-linux-uclibc/9.2.0/../../../../or1k-buildroot-linux-uclibc/bin/ld:
libc/libc_so.a(or1k_clone.os): pc-relative relocation against dynamic symbol
__syscall_error
See:
https://gitlab.com/kubu93/toolchains-builder/-/jobs/270854456
This error message come from a new check in binutils 2.32.x:
https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;a=commitdiff;h=f2c…
Right, this patch added several new validations. I am guessing the complaint is
correct and we need to fix something in uclibc-ng.
No, I haven't found a solution yet.
sysdep.h was added by commit [1] that merge the clone() code from the glibc fork
for or1k [2].
For now I disabled uClibc for or1k when building with gcc 9.x [3].
[1]
https://cgit.uclibc-ng.org/cgi/cgit/uclibc-ng.git/commit/?id=69ea4c1f65bff9…
[2]
https://github.com/openrisc/or1k-glibc/tree/master/ports/sysdeps/unix/sysv/…
[3]
https://git.buildroot.net/buildroot/commit/?id=295307700b49bada3f6e638716f0…
With binutils 2.30.x and 2.31.x, I have another
assembler error:
Error: junk at end of line `l.movhi r17,gotoffha(.LC0)'
ork1 support was added to gcc 9.x and enabled into Buildroot recently.
https://git.buildroot.net/buildroot/commit/?id=da70a55a1955ff673e0110bacb3d…
The above error comes because we need binutils 2.32.x with the new toolchain.
Indeed, I figured out that binutils >= 2.32 was mandatory to use gcc 9.1 [4].
[4]
https://git.buildroot.net/buildroot/commit/?id=e0ba09768eb27872e86857549526…
I remember doing a test with qemu_or1k_defconfig
before gcc 9.1 was released but
I don't remember if it was with musl or uClibc-ng... It should be with uClibc-ng
but I didn't trigged such error.
Thoughts ?
It's likely the new validations added with binutils 2.32.x. I'll try to build
uclibc-ng and see if I can reproduce.
You can reproduce easily by using Buildroot from master branch and reverting the
patch [3]. I runtime tested the new or1k toolchain using musl libc by using the
Buildroot defconfig qemu_or1k_defconfig.
Best regards,
Romain
-Stafford