On Fri, Nov 22, 2024 at 5:11 PM wrote:
> Sounds awfully familiar...so is this a compiler bug?
What, did you think if was *my* code that's broken? :D :D :D
> How should I go
> forward here?
Most importantly, please report this to GCC developers.
You could use the preprocessed source so they don
Sergey Bugaev writes:
> On Fri, Nov 22, 2024 at 4:28 PM wrote:
>> using the (amazing) command-line that glibc creates
>>
>> --8<---cut here---start->8---
>> $ x86_64-pc-gnu-gcc ../sysdeps/mach/hurd/x86_64/sigreturn.c -c
[..]
>
> You could now make use of this
On Fri, Nov 22, 2024 at 4:28 PM wrote:
> using the (amazing) command-line that glibc creates
>
> --8<---cut here---start->8---
> $ x86_64-pc-gnu-gcc ../sysdeps/mach/hurd/x86_64/sigreturn.c -c -std=gnu11
> -fgnu89-inline -g -O2 -Wall -Wwrite-strings -Wundef -fm
Sergey Bugaev writes:
Hello Sergey,
> On Fri, Nov 22, 2024 at 1:52 PM wrote:
>> Hi!
>
> Hi Janneke,
>
>> I have bisected the problem to be in sigaction.o: when linking with
>> sigaction.o from Debian's libcrt.a it passes, when using Guix's
>> sigaction.o it fails. Problem solved, you would say?
On Fri, Nov 22, 2024 at 1:52 PM wrote:
> Hi!
Hi Janneke,
> I have bisected the problem to be in sigaction.o: when linking with
> sigaction.o from Debian's libcrt.a it passes, when using Guix's
> sigaction.o it fails. Problem solved, you would say?
I assume you mean sigreturn.o, not sigaction.o
