Skip to content

buildGraalvmNativeImage: use lib.extendMkDerivation#1

Merged
bengsparks merged 14 commits intobengsparks:bGVM2from
philiptaron:pr-413663/buildGraalvmNativeImage
Jun 10, 2025
Merged

buildGraalvmNativeImage: use lib.extendMkDerivation#1
bengsparks merged 14 commits intobengsparks:bGVM2from
philiptaron:pr-413663/buildGraalvmNativeImage

Conversation

@philiptaron
Copy link
Copy Markdown

This additional PR continues the work you started in NixOS#413663.

  • Switch to lib.extendMkDerivation
  • Convert all users of buildGraalvmNativeImage to use finalAttrs style
  • Simplify buildGraalvmNativeImage further after the users are converted

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:
  • 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.

@philiptaron
Copy link
Copy Markdown
Author

@bengsparks

@bengsparks
Copy link
Copy Markdown
Owner

bengsparks commented Jun 5, 2025

@philiptaron Thanks very much for your work 😄 I'd reviewed this PR yesterday evening, and my tooling indicated that nativeImageBuildArgs in the parameter attribute set does not get used, but I think that's just a tooling bug? Can we just double-check that?
I've built all the packages that are affected by this PR already, so everything else LGTM.

@philiptaron philiptaron force-pushed the pr-413663/buildGraalvmNativeImage branch from 3276ef6 to 9411ce5 Compare June 5, 2025 19:48
@philiptaron
Copy link
Copy Markdown
Author

philiptaron commented Jun 5, 2025

Yeah, it wasn't used, since I switched in the final commit to args.nativeImageBuildArgs to pull it out. Updated.

@bengsparks bengsparks changed the base branch from bGVM to bGVM2 June 10, 2025 01:51
@bengsparks bengsparks merged commit 0665ba8 into bengsparks:bGVM2 Jun 10, 2025
bengsparks pushed a commit that referenced this pull request Feb 8, 2026
On my systems there is a path in the fonts list that looks like
/nix/store/<hash>-<font>.ttf. The previous code assumed that every font path
contains at least one more slash which isn't the case here.

The code matched on the / after the $out path of the derivation:

/nix/store/<hash>-<name>/share/X11/fonts/...
                        ^

That slash only exists if the font lives in a subdirectory, which
isn't strictly required. In my case I've a few font files that are
located at /nix/store/<hash>-<name>.ttf and are assembled into a
folder as symlinks. (See example below)

Any attempt at calling realpath(3) on them (potentially recursively)
will result in the single file entry in the store being returned.

Whenever that font is being loaded flatpak segfaulted like so:

```
(gdb) bt
#0  0x00005583b3673763 in get_nix_closure ()
#1  0x00005583b3673711 in get_nix_closure ()
NixOS#2  0x00005583b36737dc in add_nix_store_symlink_targets ()
NixOS#3  0x00005583b36749a8 in add_font_path_args ()
NixOS#4  0x00005583b367b3f4 in flatpak_run_app ()
NixOS#5  0x00005583b35e4f08 in flatpak_builtin_run ()
NixOS#6  0x00005583b35a5970 in main ()
(gdb) x/5i $rip
=> 0x5583b3673763 <get_nix_closure+307>:	movb   $0x0,(%rax)
   0x5583b3673766 <get_nix_closure+310>:	call   0x5583b35a46a0 <g_hash_table_add@plt>
   0x5583b367376b <get_nix_closure+315>:	jmp    0x5583b3673699 <get_nix_closure+105>
   0x5583b3673770 <get_nix_closure+320>:	xor    %edi,%edi
   0x5583b3673772 <get_nix_closure+322>:	lea    0x30475(%rip),%rsi        # 0x5583b36a3bee
(gdb) x/s $rsi
0x5583e92d2180:	"/nix/store/<hash>-A.ttf"
(gdb) print $rax
$1 = 0
```

RAX pointing to 0 here corresponds to the pointer `p` in the source
code. So the code attempted to dereference a null pointer as no further
slash (the return value of strchr(3)) could be found.

The modification in this commit ensures that we check for `p != 0` so
we don't run into this situation again.

Adding the path to the closure will still be done, even if no further
slash can be found, as that still points to a valid store path.

----

Nix code for custom fonts:

```nix
let
  files = [
    ./A.ttf
    ./B.ttf
  ];
in
runCommandNoCC "custom-fonts" {} ''
  mkdir -p $out/share/fonts/truetype
  cd $out/share/fonts/truetype
  ${ lib.concatStringsSep "\n" (map (file: "ln -s ${file} ${baseNameOf file}") files)}
''
```
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants