In reply to @rosscomputerguy:matrix.org
Oh good, nobody consumes pkgsLLVM in nixpkgs

In reply to @aleksana:mozilla.org
@[Tristan Ross] I think for the two PRs of mine, if the next staging-next rebuilds the world, we let it in, otherwise we wait until branch off

In reply to @rosscomputerguy:matrix.org
I remember doing a tall at Planet Nix about the different channels but I forget what they each do lol.

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?