[uclibc-ng-devel] [ork1] issue with Binutils 2.32 and gcc 9.x

Romain Naour romain.naour at gmail.com
Sat Aug 24 14:45:59 CEST 2019

Hi Stafford,

Le 23/08/2019 à 23:01, Stafford Horne a écrit :
> On Fri, Aug 23, 2019 at 05:23:12PM +0200, Romain Naour wrote:
>> 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...
> I was able to reproduce the issue and did a temporary fix by just deleting the
> __syscall_error from or1k_clone.S (2 places).  This fixed the build but probably
> not something we really want to do.  But it does point out that the only bad
> symbol is the one in or1k_clone.S.

I don't get it, there is only SYSCALL_ERROR_NAME from or1k_clone.S.
Maybe post the patch diff here.

> There is a glibc port I am working on getting working right now:
>   https://github.com/stffrdhrn/or1k-glibc/blob/upstream-rebase/sysdeps/unix/sysv/linux/or1k/or1k_clone.S
> It seems to have the same code.  But it does not have this problem.  The macro
> for SYSCALL_ERROR_NAME is probably getting evaluated differently in glibc vs
> uclibc-ng.

Maybe something doesn't work with the way we define SYSCALL_ERROR_NAME
> This fix should not be too hard.  SYSCALL_ERROR_NAME is only being used on
> or1k_clone.S.  Let's try to see what is the right thing to replace it with for
> uclibc-ng.

I haven't looked in depth in the code, I'm not sure how to fix this :-/

Best regards,

> -Stafford 

More information about the devel mailing list