DRAFT: remove dependency on deprecated libcxxabi package

[mklca]

Since NixOS/nixpkgs#292043 the libcxxabi package was functionally integrated into libcxx and is no longer required―indeed, using it now throws.

• Remove all uses of libcxxabi from the compiler build (which already references libcxx in all the same places.)

• Update the package alias to forward c++abi to cxxabi rather than libcxxabi

[mklca]

Since I didn't update flake.lock the nixpkgs dependencies likely won't have the required changes and the CI checks will probably fail. So this patch needs to go in with a resync of nixpkgs.

As far as how we handle some of the “legacy” nixpkgs versions which will probably never see this change to libcxx backported, I have no ideas beyond adding some sort of conditional logic to use libcxxabi.

[ghost]

Since I didn't update flake.lock the nixpkgs dependencies likely won't have the required changes and the CI checks will probably fail. So this patch needs to go in with a resync of nixpkgs.

As far as how we handle some of the “legacy” nixpkgs versions which will probably never see this change to libcxx backported, I have no ideas beyond adding some sort of conditional logic to use libcxxabi.

something like:

${toString (map (l: "${lib.getLib l}/lib") ([ libcxx ] ++ lib.optional (libcxx ? cxxabi) libcxx.cxxabi))}

and then

libcxx.cxxabi or libcxx

might work for the conditional logic to work with old nixpkgs.

[angerman]

Thank you @a-n-n-a-l-e-e for jumping in with the suggestion.
@mklca thank you for the PR! We will need some form of backwards compatibility though as we target multiple nixpkgs revisions.

[mklca]

Obviously this is a draft of what needs to happen. @a-n-n-a-l-e-e's idea seems like a good way to handle the backwards compatibility. I'll iterate on that this week.

While I'm at it, how would you like to address the removal of gtkpod from nixpkgs that breaks lib/pkgconf-nixpkgs-map.nix? This is an implicit point of coupling to different releases of nixpkgs and it seems like that should be reified somehow.

[angerman]

Obviously this is a draft of what needs to happen. @a-n-n-a-l-e-e's idea seems like a good way to handle the backwards compatibility. I'll iterate on that this week.

While I'm at it, how would you like to address the removal of gtkpod from nixpkgs that breaks lib/pkgconf-nixpkgs-map.nix? This is an implicit point of coupling to different releases of nixpkgs and it seems like that should be reified somehow.

I think we'll want to conditionally map that to null.

[angerman]

@mklca ohh! That gtkpod thing is trickier than I thought. I'm trying d3570f0 to be a bit more robust against throws in nixpkgs.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.