!OqhvaDMJdKYUicLDiE:nixos.org

Nixpkgs Stdenv

222 Members
72 Servers

Load older messages

SenderMessageTime
20 Apr 2025
@aleksana:mozilla.orgaleksana (force me to bed after 18:00 UTC) @[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 16:48:04
@aleksana:mozilla.orgaleksana (force me to bed after 18:00 UTC)So we don't waste anything16:48:17
@rosscomputerguy:matrix.orgTristan Ross
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
I think that sounds fine 		16:50:23
@aleksana:mozilla.orgaleksana (force me to bed after 18:00 UTC)If we don't fix it at all, people would not be able to create new bootstrap tarballs for exotic architectures following our guide, which can be considered as a regression caused by gcc14 update16:53:19
@aleksana:mozilla.orgaleksana (force me to bed after 18:00 UTC)* If we don't fix it at all, people would not be able to use new bootstrap tarballs for exotic architectures following our guide, which can be considered as a regression caused by gcc14 update16:54:07
@emilazy:matrix.orgemily -next is pretty much guaranteed to rebuild the world 17:00:04
@emilazy:matrix.orgemily it's likely there are already stdenv rebuilds in staging 17:00:17
@emilazy:matrix.orgemilycertainly I'm going to add one for Darwin ASAP17:00:24
@rosscomputerguy:matrix.orgTristan RossI remember doing a tall at Planet Nix about the different channels but I forget what they each do lol.17:01:47
@rosscomputerguy:matrix.orgTristan Ross* I remember doing a talk at Planet Nix about the different channels but I forget what they each do lol.17:01:56
@aleksana:mozilla.orgaleksana (force me to bed after 18:00 UTC)
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.
I fixed the graph at some point so I can't forget it 		17:09:22
@reckenrode:matrix.orgRandy Eckenrode That would break Wine and DXVK. What is the replacement for things that need to build Windows DLLs? Wine’s use of MinGW is kind of bad (because it mixes cross- and native tools in an ugly way), but DXVK builds things as cross-to-Windows then symlinks those from the unversioned dxvk derivation). 17:57:39
@reckenrode:matrix.orgRandy EckenrodeI intend to package DXMT, which uses LLVM plus deps. I just haven’t had time (and it needs Wine patches, which sucks).17:58:51
@reckenrode:matrix.orgRandy Eckenrode* I intend to package DXMT, which uses LLVM plus deps. I just haven’t had time (and it needs Wine patches, which kind of sucks).17:59:03
@rosscomputerguy:matrix.orgTristan RossI'm not sure what the solution is but we're not moving everything over until after the release this PR is merged in lol17:59:36
@rosscomputerguy:matrix.orgTristan Ross So we do have time to come up with a solution 17:59:46
@rosscomputerguy:matrix.orgTristan RossDXMT sounds like a good solution18:00:06
@reckenrode:matrix.orgRandy EckenrodeI’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.18:03:38
@emilazy:matrix.orgemilydoes it actually depend on Nixpkgs-packaged Windows stuff at runtime?18:04:30
@reckenrode:matrix.orgRandy EckenrodeI also would like to rewrite the Wine derivation to be less ugly and support aarch64. I saw something on r/asahilinux about using FEX with Wine itself, so you could end up with a Wine that supports x86, x86_64, and arm64ec.18:04:33
@reckenrode:matrix.orgRandy EckenrodeYes. One of the things it builds a DLL that exposes Metal to the Windows side.18:06:23
@reckenrode:matrix.orgRandy EckenrodeIt’s like DXVK but for Metal.18:06:37
@reckenrode:matrix.orgRandy Eckenrode* Yes. One of the things it builds is a DLL that exposes Metal to the Windows side.18:06:52
@reckenrode:matrix.orgRandy Eckenrode(DXVK can rely on Wine’s Vulkan implementation, but there’s nothing equivalent out of the box for Metal.)18:09:36
@cldrpr:matrix.orgcldrpr

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?

18:47:16
@cldrpr:matrix.orgcldrpr *

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?

18:49:37
@cldrpr:matrix.orgcldrpr *

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?

19:19:51
@rosscomputerguy:matrix.orgTristan Ross @cldrpr lemme give it a try on my aarch64 hardware to see if cross is borked, though that doesn't look like cross for what you're doing. That looks like emulated compiling. 19:52:55
@rosscomputerguy:matrix.orgTristan Ross
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.
I think it's doable but we'll have to explore our options when we're closer to that stage 		19:53:19
@trofi:matrix.orgtrofi I would expect libssp not to be needed on aarch64. MOst targets should provide __stack_chk_fail and friends from libc. 19:54:59

Show newer messages

Back to Room ListRoom Version: 9