Hi! Stdenv noob here.

Re: #295038, I have been working on understanding the next-gen GCC split-up efforts (John Ericson Philip Taron (UTC-8) ). I wanted to bounce some issues around to see if anyone may have any insight/perspective.

I've brought in changes from master (from a few weeks ago) into my working branch here. Per John Ericson's guidance, my focus is on getting cross-compilation functional. For testing, I am using the following build command from an x86 machine: nix-build --arg 'crossSystem' '{ config = "aarch64-unknown-linux-gnu"; useGccNg = true; }' -A <pkg>.

For additional background, the main gccNg top-level package is located here. The surface-level issue that I am currently finding is that building gccNgPackages.libssp fails with the following error:

       > ../sysdeps/aarch64/nptl/tls.h:86:21: error: implicit declaration of function '__builtin_thread_pointer'; did you mean '__builtin_extend_pointer'? []
       >    86 |  ((struct pthread *)__builtin_thread_pointer () - 1)
       >       |                     ^~~~~~~~~~~~~~~~~~~~~~~~
       > ../sysdeps/nptl/pthreadP.h:266:26: note: in expansion of macro 'THREAD_SELF'
       >   266 |   struct pthread *self = THREAD_SELF;
       >       |                          ^~~~~~~~~~~
       > ../sysdeps/aarch64/nptl/tls.h:86:3: error: cast to pointer from integer of different size []
       >    86 |  ((struct pthread *)__builtin_thread_pointer () - 1)
       >       |   ^
       > ../sysdeps/nptl/pthreadP.h:266:26: note: in expansion of macro 'THREAD_SELF'
       >   266 |   struct pthread *self = THREAD_SELF;
       >       |                          ^~~~~~~~~~~
       > ../sysdeps/nptl/libc_start_call_main.h: In function '__libc_start_call_main':
       > ../sysdeps/aarch64/nptl/tls.h:86:3: error: cast to pointer from integer of different size []
       >    86 |  ((struct pthread *)__builtin_thread_pointer () - 1)
       >       |   ^
       > ../sysdeps/nptl/libc_start_call_main.h:48:30: note: in expansion of macro 'THREAD_SELF'
       >    48 |       struct pthread *self = THREAD_SELF;

libssp uses gccWithLibc. This appears to be the point of failure. gccWithLibc wraps gcc-unwrapped with default bintools and the preceding libgcc. The preceding (and last successful build) libgcc stage uses gccWithLibgcc, which has bintoolsNoLibc in the CC wrapper.

I have made the assumption that the error is arch-related. Testing this assumption, I found the gccWithLibc stage in the build uses targetPackages.bintools. To test further, I passed buildPackages.bintools to gccWithLibc - and the build succeeds, though this causes subsequent issues in the following stage. Does this suggest an issue in recursion somewhere in the toolchain?

Does anyone have any thoughts?

Hi! Stdenv noob here.

Re: #295038, I have been working on understanding the next-gen GCC split-up efforts (John Ericson Philip Taron (UTC-8) ). I wanted to bounce some issues around to see if anyone may have any insight/perspective.

I've brought in changes from master (from a few weeks ago) into my working branch here. Per John Ericson's guidance, my focus is on getting cross-compilation functional. For testing, I am using the following build command from an x86 machine: nix-build --arg 'crossSystem' '{ config = "aarch64-unknown-linux-gnu"; useGccNg = true; }' -A <pkg>.

For additional background, the main gccNg top-level package is located here. The surface-level issue that I am currently finding is that building gccNgPackages.libssp fails with the following error:

       > ../sysdeps/aarch64/nptl/tls.h:86:21: error: implicit declaration of function '__builtin_thread_pointer'; did you mean '__builtin_extend_pointer'? []
       >    86 |  ((struct pthread *)__builtin_thread_pointer () - 1)
       >       |                     ^~~~~~~~~~~~~~~~~~~~~~~~
       > ../sysdeps/nptl/pthreadP.h:266:26: note: in expansion of macro 'THREAD_SELF'
       >   266 |   struct pthread *self = THREAD_SELF;
       >       |                          ^~~~~~~~~~~
       > ../sysdeps/aarch64/nptl/tls.h:86:3: error: cast to pointer from integer of different size []
       >    86 |  ((struct pthread *)__builtin_thread_pointer () - 1)
       >       |   ^
       > ../sysdeps/nptl/pthreadP.h:266:26: note: in expansion of macro 'THREAD_SELF'
       >   266 |   struct pthread *self = THREAD_SELF;
       >       |                          ^~~~~~~~~~~
       > ../sysdeps/nptl/libc_start_call_main.h: In function '__libc_start_call_main':
       > ../sysdeps/aarch64/nptl/tls.h:86:3: error: cast to pointer from integer of different size []
       >    86 |  ((struct pthread *)__builtin_thread_pointer () - 1)
       >       |   ^
       > ../sysdeps/nptl/libc_start_call_main.h:48:30: note: in expansion of macro 'THREAD_SELF'
       >    48 |       struct pthread *self = THREAD_SELF;

libssp uses gccWithLibc. This appears to be the point of failure. gccWithLibc wraps gcc-unwrapped with default bintools and the preceding libgcc. The preceding (and last successful build) libgcc stage uses gccWithLibgcc, which has bintoolsNoLibc in the CC wrapper.

I have made the assumption that the error is arch-related. Testing this assumption, I found the gccWithLibc stage in the build uses targetPackages.bintools. To test further, I passed buildPackages.bintools to gccWithLibc - and the build succeeds, though this causes subsequent issues in the following stage. Does this suggest an issue in recursion somewhere in the toolchain or perhaps with configure flags?

Does anyone have any thoughts?

Hi! Stdenv noob here.

Re: #295038, I have been working on understanding the next-gen GCC split-up efforts (John Ericson Philip Taron (UTC-8) ). I wanted to bounce some issues around to see if anyone may have any insight/perspective.

I've brought in changes from master (from a few weeks ago) into my working branch here. Per John Ericson's guidance, my focus is on getting cross-compilation functional. For testing, I am using the following build command from an x86 machine: nix-build --arg 'crossSystem' '{ config = "aarch64-unknown-linux-gnu"; useGccNg = true; }' -A <pkg>.

For additional background, the main gccNg top-level package is located here. The surface-level issue that I am currently finding is that building gccNgPackages.libssp fails with the following error:

       > ../sysdeps/aarch64/nptl/tls.h:86:21: error: implicit declaration of function '__builtin_thread_pointer'; did you mean '__builtin_extend_pointer'? []
       >    86 |  ((struct pthread *)__builtin_thread_pointer () - 1)
       >       |                     ^~~~~~~~~~~~~~~~~~~~~~~~
       > ../sysdeps/nptl/pthreadP.h:266:26: note: in expansion of macro 'THREAD_SELF'
       >   266 |   struct pthread *self = THREAD_SELF;
       >       |                          ^~~~~~~~~~~
       > ../sysdeps/aarch64/nptl/tls.h:86:3: error: cast to pointer from integer of different size []
       >    86 |  ((struct pthread *)__builtin_thread_pointer () - 1)
       >       |   ^
       > ../sysdeps/nptl/pthreadP.h:266:26: note: in expansion of macro 'THREAD_SELF'
       >   266 |   struct pthread *self = THREAD_SELF;
       >       |                          ^~~~~~~~~~~
       > ../sysdeps/nptl/libc_start_call_main.h: In function '__libc_start_call_main':
       > ../sysdeps/aarch64/nptl/tls.h:86:3: error: cast to pointer from integer of different size []
       >    86 |  ((struct pthread *)__builtin_thread_pointer () - 1)
       >       |   ^
       > ../sysdeps/nptl/libc_start_call_main.h:48:30: note: in expansion of macro 'THREAD_SELF'
       >    48 |       struct pthread *self = THREAD_SELF;

libssp uses gccWithLibc. This appears to be the point of failure. gccWithLibc wraps gcc-unwrapped with default bintools and the preceding libgcc. The preceding (and last successful build) libgcc stage uses gccWithLibgcc, which has bintoolsNoLibc in the CC wrapper.

I have made one assumption that the error is possibly arch-related. Testing this assumption, I found the gccWithLibc stage in the build uses targetPackages.bintools. To test further, I passed buildPackages.bintools to gccWithLibc - and the build succeeds, though this causes subsequent issues in the following stage. Does this suggest an issue in recursion somewhere in the toolchain or perhaps with configure flags?

Does anyone have any thoughts?

In reply to @reckenrode:matrix.org
I’m not sure how to structure DXMT. It’s a mix of native and Windows stuff. Ideally, cross from aarch64-darwin should build x86_64-darwin and x86_64-windows stuff.

In reply to @trofi:matrix.org
I would expect libssp not to be needed on aarch64. MOst targets should provide __stack_chk_fail and friends from libc.

In reply to @rosscomputerguy:matrix.org
I wonder if the GCC refactoring could fix https://github.com/NixOS/nixpkgs/pull/399656#issuecomment-2814602431 lol

In reply to @rosscomputerguy:matrix.org
I wonder if the GCC refactoring could fix https://github.com/NixOS/nixpkgs/pull/399656#issuecomment-2814602431 lol

In reply to @reckenrode:matrix.org
Is the goal to enable LTO for everything? That seems risky for packages not written with LTO in mind (e.g., ld64 is prone to crashing when built LTO enabled).