orca-slicer: fix gcc14

[liberodark]

• Fix Build failure: orca-slicer #369571

Things done

• Built on platform(s)
  • x86_64-linux
  • aarch64-linux
  • x86_64-darwin
  • aarch64-darwin
• For non-Linux: Is sandboxing enabled in nix.conf? (See Nix manual)
  • sandbox = relaxed
  • sandbox = true
• Tested, as applicable:
  • NixOS test(s) (look inside nixos/tests)
  • and/or package tests
  • or, for functions and "core" functionality, tests in lib/tests or pkgs/test
  • made sure NixOS tests are linked to the relevant packages
• Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage
• Tested basic functionality of all binary files (usually in ./result/bin/)
• 25.05 Release Notes (or backporting 24.11 and 25.05 Release notes)
  • (Package updates) Added a release notes entry if the change is major or breaking
  • (Module updates) Added a release notes entry if the change is significant
  • (Module addition) Added a release notes entry if adding a new NixOS module
• Fits CONTRIBUTING.md.

---

Add a 👍 reaction to pull requests you find important.

[liberodark]

Ok have fixe somes issues from GCC14 is done but have mesa issue :

Full
https://paste.yunohost.org/oquvowijuf.rust

/nix/store/j7p46r8v9gcpbxx89pbqlh61zhd33gzv-binutils-2.43.1/bin/ld: /nix/store/jv1qyylqn50pzzfwjpc8sb7lxfqpxfpq-mesa-24.3.2-osmesa/lib/libOSMesa.so: undefined reference to `_glapi_set_dispatch'
/nix/store/j7p46r8v9gcpbxx89pbqlh61zhd33gzv-binutils-2.43.1/bin/ld: /nix/store/jv1qyylqn50pzzfwjpc8sb7lxfqpxfpq-mesa-24.3.2-osmesa/lib/libOSMesa.so: undefined reference to `_glapi_get_dispatch_table_size'
/nix/store/j7p46r8v9gcpbxx89pbqlh61zhd33gzv-binutils-2.43.1/bin/ld: /nix/store/jv1qyylqn50pzzfwjpc8sb7lxfqpxfpq-mesa-24.3.2-osmesa/lib/libOSMesa.so: undefined reference to `_glapi_set_context'
/nix/store/j7p46r8v9gcpbxx89pbqlh61zhd33gzv-binutils-2.43.1/bin/ld: /nix/store/jv1qyylqn50pzzfwjpc8sb7lxfqpxfpq-mesa-24.3.2-osmesa/lib/libOSMesa.so: undefined reference to `_glapi_get_context'
/nix/store/j7p46r8v9gcpbxx89pbqlh61zhd33gzv-binutils-2.43.1/bin/ld: /nix/store/jv1qyylqn50pzzfwjpc8sb7lxfqpxfpq-mesa-24.3.2-osmesa/lib/libOSMesa.so: undefined reference to `_glapi_get_dispatch'
/nix/store/j7p46r8v9gcpbxx89pbqlh61zhd33gzv-binutils-2.43.1/bin/ld: /nix/store/jv1qyylqn50pzzfwjpc8sb7lxfqpxfpq-mesa-24.3.2-osmesa/lib/libOSMesa.so: undefined reference to `_glapi_get_proc_address'
/nix/store/j7p46r8v9gcpbxx89pbqlh61zhd33gzv-binutils-2.43.1/bin/ld: /nix/store/jv1qyylqn50pzzfwjpc8sb7lxfqpxfpq-mesa-24.3.2-osmesa/lib/libOSMesa.so: undefined reference to `_glapi_tls_Dispatch'
/nix/store/j7p46r8v9gcpbxx89pbqlh61zhd33gzv-binutils-2.43.1/bin/ld: /nix/store/jv1qyylqn50pzzfwjpc8sb7lxfqpxfpq-mesa-24.3.2-osmesa/lib/libOSMesa.so: undefined reference to `_glapi_tls_Context'
/nix/store/j7p46r8v9gcpbxx89pbqlh61zhd33gzv-binutils-2.43.1/bin/ld: /nix/store/jv1qyylqn50pzzfwjpc8sb7lxfqpxfpq-mesa-24.3.2-osmesa/lib/libOSMesa.so: undefined reference to `_glapi_add_dispatch'
collect2: error: ld returned 1 exit status

[Atemu]

Are your drivers from the same Nixpkgs revision as the package?

[FliegendeWurst]

You probably want to include SoftFever/OrcaSlicer#7884 instead of using Boost 1.80.

[FliegendeWurst]

To make the package version compliant and ready for strictDeps (#178468):

diff --git a/pkgs/by-name/or/orca-slicer/package.nix b/pkgs/by-name/or/orca-slicer/package.nix
index 1dcfc55254cd..d013f52b10df 100644
--- a/pkgs/by-name/or/orca-slicer/package.nix
+++ b/pkgs/by-name/or/orca-slicer/package.nix
@@ -56,12 +56,12 @@ let
 in
 stdenv.mkDerivation rec {
   pname = "orca-slicer";
-  version = "2f55dd7cfe3e3d2c41fdd73dddc31f1c5dcbdf83";
+  version = "2.2.0-unstable-2025-01-01";
 
   src = fetchFromGitHub {
     owner = "SoftFever";
     repo = "OrcaSlicer";
-    rev = version;
+    rev = "2f55dd7cfe3e3d2c41fdd73dddc31f1c5dcbdf83";
     hash = "sha256-2JHGNVKLJ5aJlcS0KCdegrTmj80utT5sfKO6XlG9blg=";
   };
 
@@ -69,6 +69,7 @@ stdenv.mkDerivation rec {
     cmake
     pkg-config
     wrapGAppsHook3
+    wxGTK'
   ];
 
   buildInputs =

[liberodark]

Now is running but the last issue is :

MESA-LOADER: failed to open dri: /run/opengl-driver/lib/gbm/dri_gbm.so: cannot open shared object file: No such file or directorMESA-LOADER: failed to open dri: /run/opengl-driver/lib/gbm/dri_gbm.so: cannot open shared object file: No such file or directory (search paths /run/opengl-driver/lib/gbm, suffix _gbm)
y (search paths /run/opengl-driver/lib/gbm, suffix _gbm)
Failed to create GBM device for DRM node: /dev/dri/renderD128: No such file or directory
Failed to create GBM device for DRM node: /dev/dri/renderD128: No such file or directory
MESA-LOADER: failed to open dri: /run/opengl-driver/lib/gbm/dri_gbm.so: cannot open shared object file: No such file or directory (search paths /run/opengl-driver/lib/gbm, suffix _gbm)
Failed to create GBM device for DRM node: /dev/dri/renderD128: No such file or directory
MESA-LOADER: failed to open dri: /run/opengl-driver/lib/gbm/dri_gbm.so: cannot open shared object file: No such file or directory (search paths /run/opengl-driver/lib/gbm, suffix _gbm)
Failed to create GBM device for DRM node: /dev/dri/renderD128: No such file or directory

[Atemu]

Are your drivers from the same Nixpkgs revision as the package?

[liberodark]

nixpkgs-review result

Generated using nixpkgs-review.

Command: nixpkgs-review pr 369729

---

x86_64-linux

✅ 2 packages built:

• orca-slicer
• orca-slicer.debug

---

aarch64-linux

✅ 2 packages built:

• orca-slicer
• orca-slicer.debug

---

x86_64-darwin

---

aarch64-darwin

[liberodark]

Are your drivers from the same Nixpkgs revision as the package?

Hi, @Atemu
Im in 24.11 Stable and im build in master of nixpkgs.
So im using : mesa-24.2.6
And im building with : mesa-24.3.2

Best Regards

ldd ./result/bin/orca-slicer
	linux-vdso.so.1 (0x00007fe146521000)
	libudev.so.1 => /nix/store/lji0hh2w2rv6q9mal3vpxbg413d57vfd-systemd-256.8/lib/libudev.so.1 (0x00007fe1464c1000)
	libboost_log.so.1.86.0 => /nix/store/j7614sg25vadwbids1fahg0rjhg2s4k8-boost-1.86.0/lib/libboost_log.so.1.86.0 (0x00007fe1463de000)
	libboost_log_setup.so.1.86.0 => /nix/store/j7614sg25vadwbids1fahg0rjhg2s4k8-boost-1.86.0/lib/libboost_log_setup.so.1.86.0 (0x00007fe1462e5000)
	libc.so.6 => /nix/store/65h17wjrrlsj2rj540igylrx7fqcd6vq-glibc-2.40-36/lib/libc.so.6 (0x00007fe146000000)
	libcap.so.2 => /nix/store/6qbrzgjjhgwprggaflf33p5c9bxcz1k0-libcap-2.70-lib/lib/libcap.so.2 (0x00007fe1462d6000)
	/nix/store/65h17wjrrlsj2rj540igylrx7fqcd6vq-glibc-2.40-36/lib/ld-linux-x86-64.so.2 => /nix/store/wn7v2vhyyyi6clcyn0s9ixvl7d4d87ic-glibc-2.40-36/lib64/ld-linux-x86-64.so.2 (0x00007fe146523000)
	libboost_filesystem.so.1.86.0 => /nix/store/j7614sg25vadwbids1fahg0rjhg2s4k8-boost-1.86.0/lib/libboost_filesystem.so.1.86.0 (0x00007fe1462aa000)
	libboost_thread.so.1.86.0 => /nix/store/j7614sg25vadwbids1fahg0rjhg2s4k8-boost-1.86.0/lib/libboost_thread.so.1.86.0 (0x00007fe146289000)
	libboost_atomic.so.1.86.0 => /nix/store/j7614sg25vadwbids1fahg0rjhg2s4k8-boost-1.86.0/lib/libboost_atomic.so.1.86.0 (0x00007fe14627f000)
	libboost_chrono.so.1.86.0 => /nix/store/j7614sg25vadwbids1fahg0rjhg2s4k8-boost-1.86.0/lib/libboost_chrono.so.1.86.0 (0x00007fe146274000)
	librt.so.1 => /nix/store/65h17wjrrlsj2rj540igylrx7fqcd6vq-glibc-2.40-36/lib/librt.so.1 (0x00007fe14626d000)
	libstdc++.so.6 => /nix/store/bpq1s72cw9qb2fs8mnmlw6hn2c7iy0ss-gcc-14-20241116-lib/lib/libstdc++.so.6 (0x00007fe145c00000)
	libm.so.6 => /nix/store/65h17wjrrlsj2rj540igylrx7fqcd6vq-glibc-2.40-36/lib/libm.so.6 (0x00007fe145f17000)
	libgcc_s.so.1 => /nix/store/bpq1s72cw9qb2fs8mnmlw6hn2c7iy0ss-gcc-14-20241116-lib/lib/libgcc_s.so.1 (0x00007fe14623f000)
	libpthread.so.0 => /nix/store/65h17wjrrlsj2rj540igylrx7fqcd6vq-glibc-2.40-36/lib/libpthread.so.0 (0x00007fe14623a000)

[Atemu]

Well yes, that isn't going to work. Mesa version needs to match. You could hack around this by building mesa.drivers from this same revision and LD_PRELOADing the relevant driver's .so.

[Atemu]

@GaetanLepage those are nitpicks/personal preference. Please mark them as such and don't block on them.

[GaetanLepage]

@GaetanLepage those are nitpicks/personal preference. Please mark them as such and don't block on them.

Well, I would argue that some of them are leaning towards consensual style. For instance, using tag is something that is currently being enforced treewide (#368177).

Nevertheless, I also acknowledge that I tend to nit-picking too much. Thank you for your feedback.

[Atemu]

some of them are leaning towards consensual style

There is no such consensual style. That'd require an RFC as that'd be a broader community decision.

We have that for formatting now but not for which patterns to use in derivations.

Unless there is a very good technical reason (tag or finalAttrs do not reach this bar), you're free to choose any solution.

Of course you as a reviewer can make the author aware of the existence of such patterns but you shouldn't insist on them until explicit community consensus exists.

For instance, using tag is something that is currently being enforced treewide (#368177).

It's being migrated because it's seen as an obvious improvement over the refs/tags/ boilerplate case but no migration from rev is planned and nothing is being enforced. If someone really wanted to remain on refs/tags/, sure. Again there is no consensus or significant issue.

Nevertheless, I also acknowledge that I tend to nit-picking too much. Thank you for your feedback.

Nitpicks are fine to make but their purpose should be information, not gatekeeping IMHO. You should explicitly mark them as such and not require them to be followed.

When I only have nitpicks or even some minor non-nickpick requests I usually even signal approval to make it clear that following these is optional.

[GaetanLepage]

some of them are leaning towards consensual style

There is no such consensual style. That'd require an RFC as that'd be a broader community decision.

We have that for formatting now but not for which patterns to use in derivations.

Unless there is a very good technical reason (tag or finalAttrs do not reach this bar), you're free to choose any solution.

Of course you as a reviewer can make the author aware of the existence of such patterns but you shouldn't insist on them until explicit community consensus exists.

For instance, using tag is something that is currently being enforced treewide (#368177).

It's being migrated because it's seen as an obvious improvement over the refs/tags/ boilerplate case but no migration from rev is planned and nothing is being enforced. If someone really wanted to remain on refs/tags/, sure. Again there is no consensus or significant issue.

Nevertheless, I also acknowledge that I tend to nit-picking too much. Thank you for your feedback.

Nitpicks are fine to make but their purpose should be information, not gatekeeping IMHO. You should explicitly mark them as such and not require them to be followed.

When I only have nitpicks or even some minor non-nickpick requests I usually even signal approval to make it clear that following these is optional.

Understood, thanks for sharing your point of view.