ghc cross#4
Closed
expipiplus1 wants to merge 4 commits intoobsidiansystems:ericson2314-ghc-android-haskellfrom
Closed
ghc cross#4expipiplus1 wants to merge 4 commits intoobsidiansystems:ericson2314-ghc-android-haskellfrom
expipiplus1 wants to merge 4 commits intoobsidiansystems:ericson2314-ghc-android-haskellfrom
Conversation
This prevents issues such as neurocyte/ghc-android#29
The Haddock binary is not present
Cross compilation did not work previously
Also add the native file as a build input when cross compiling
Member
|
Thanks @expipiplus1! I'm kind of deep in NixOS#26805 at the moment, but combining this with NixOS#26799 will make a better patch to rebase onto the NixOS#26805. |
Member
|
I think this works upstream now but correct me if I'm wrong! :) |
ingenieroariel
pushed a commit
that referenced
this pull request
Nov 15, 2019
… crash 1. Gnumeric has unbalanced XML tags in its doc translations. 2. itstool's XML error handler tries to print this error with context. 3. libxml2's context snipper treats the data as bytes, not UTF-8. 4. python3Packages.libxml2 casts the context to a UTF-8 Python string. 5. itstool dereferences a null pointer. This patch intervenes at #4. In https://bugzilla.gnome.org/show_bug.cgi?id=789714#c4 , upstream suggests that intervening at #3 would be better -- that each of the four copies of xmlParserPrintFileContextInternal() have four additional UTF-8 problems, one of which is that the caret indicator ought to count "unicode characters" not bytes. But to position a caret correctly, a character count is not sufficient -- this would need to use icu's BiDi logic (with fallback to doing something wrong when libxml2 is configured not to use icu) -- which makes a 'correct' fix a much larger project than this simple band-aid.
Ericson2314
pushed a commit
that referenced
this pull request
Jan 4, 2023
Without this change it segfaults when trying to play any media: $ jellyfinmediaplayer Warning: Ignoring XDG_SESSION_TYPE=wayland on Gnome. Use QT_QPA_PLATFORM=wayland to run on Wayland anyway. libpng warning: iCCP: known incorrect sRGB profile Logging to /home/bf/.local/share/jellyfinmediaplayer/logs/jellyfinmediaplayer.log Cannot load libcuda.so.1 Segmentation fault (core dumped) The backtrace shows pipewire being at fault: $ coredumpctl debug [...] Program terminated with signal SIGSEGV, Segmentation fault. #0 0x00007f711428c9bb in core_event_demarshal_remove_id () from /nix/store/nhffrd7f15dhfbkwzgayq7hhzmdvdy19-pipewire-0.3.63-lib/lib/pipewire-0.3/libpipewire-module-protocol-native.so [Current thread is 1 (Thread 0x7f6ffdc87640 (LWP 1360949))] (gdb) bt #0 0x00007f711428c9bb in core_event_demarshal_remove_id () from /nix/store/nhffrd7f15dhfbkwzgayq7hhzmdvdy19-pipewire-0.3.63-lib/lib/pipewire-0.3/libpipewire-module-protocol-native.so #1 0x00007f711428886c in process_remote () from /nix/store/nhffrd7f15dhfbkwzgayq7hhzmdvdy19-pipewire-0.3.63-lib/lib/pipewire-0.3/libpipewire-module-protocol-native.so #2 0x00007f7114288e68 in on_remote_data () from /nix/store/nhffrd7f15dhfbkwzgayq7hhzmdvdy19-pipewire-0.3.63-lib/lib/pipewire-0.3/libpipewire-module-protocol-native.so #3 0x00007f7114310efe in loop_iterate () from /nix/store/nhffrd7f15dhfbkwzgayq7hhzmdvdy19-pipewire-0.3.63-lib/lib/spa-0.2/support/libspa-support.so #4 0x00007f71266fe7f2 in do_loop () from /nix/store/nhffrd7f15dhfbkwzgayq7hhzmdvdy19-pipewire-0.3.63-lib/lib/libpipewire-0.3.so.0 #5 0x00007f7128b08e86 in start_thread () from /nix/store/ayfr5l52xkqqjn3n4h9jfacgnchz1z7s-glibc-2.35-224/lib/libc.so.6 #6 0x00007f7128b8fce0 in clone3 () from /nix/store/ayfr5l52xkqqjn3n4h9jfacgnchz1z7s-glibc-2.35-224/lib/libc.so.6 (gdb) Standalone mpv doesn't segfault (when directly playing the underlying media files). I don't know why. Fixes: b97cda7 ("mpv-unwrapped: 0.34.1 -> 0.35.0") Fixes NixOS#205141 Ref jellyfin/jellyfin-desktop#341 (cherry picked from commit 3c528bc)
Ericson2314
pushed a commit
that referenced
this pull request
Feb 6, 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 ()
#2 0x00005583b36737dc in add_nix_store_symlink_targets ()
#3 0x00005583b36749a8 in add_font_path_args ()
#4 0x00005583b367b3f4 in flatpak_run_app ()
#5 0x00005583b35e4f08 in flatpak_builtin_run ()
#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)}
''
```
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Some minor changes I had to make to get things working for me.
CC @Ericson2314