[SOLVED] Dynamic linker is segfaulting

Engdyn · 2026-07-29 00:38:47

I updated my system a few hours ago and wanted to play something in Retroarch. I'm starting the core and it instantly segfaults.

Jul 29 00:42:44 EVA-01 kernel: retroarch[21510]: segfault at 0 ip 00007f07dab71689 sp 00007ffd0d026ec8 error 6 in libc.so.6[171689,7f07daa24000+175000] likely on CPU 8 (core 0, socket 0)
Jul 29 00:42:44 EVA-01 kernel: Code: 20 c5 fe 7f 07 c5 fe 7f 44 17 e0 c5 f8 77 c3 66 90 c5 fe 7f 47 c0 c5 fe 7f 47 e0 c5 f8 77 c3 66 90 48 3b 15 91 0b 0a 00 77 77 <c5> fe 7f 07 c5 fe 7f 47 20 48 01 d7 48 81 fa 80 00 00 00 76 d2 c5
Jul 29 00:42:44 EVA-01 systemd-coredump[21556]: Process 21510 (retroarch) of user 1000 terminated abnormally with signal 11/SEGV, processing...
Jul 29 00:42:44 EVA-01 systemd[1]: Started Process Core Dump (PID 21556/UID 0).
Jul 29 00:42:44 EVA-01 systemd[1]: Started Pass systemd-coredump journal entries to relevant user for potential DrKonqi handling.
Jul 29 00:42:45 EVA-01 systemd-coredump[21557]: [?] Process 21510 (retroarch) of user 1000 dumped core.

The first thing I always do is to compile the package in a chroot and test it. I'm going into my source directory and run "pkgctl build". Everything seems to work fine until KDE Plasma notifies me that the dynamic linker segfaulted too.

Jul 29 01:15:54 EVA-01 sudo[25729]:     engdyn : TTY=pts/1 ; PWD=/home/engdyn/.cache/paru/clone/libretro-wasm4-git ; USER=root ; COMMAND=/usr/bin/extra-x86_64-build -- -l engdyn-1 --
Jul 29 01:15:54 EVA-01 sudo[25729]: pam_unix(sudo:session): session opened for user root(uid=0) by engdyn(uid=1000)
Jul 29 01:15:56 EVA-01 systemd[1]: Started Container arch-nspawn-25775.
Jul 29 01:15:57 EVA-01 systemd[1]: arch-nspawn-25775.scope: Deactivated successfully.
Jul 29 01:15:57 EVA-01 systemd[1]: run-systemd-nspawn-arch\x2dnspawn\x2d25775-unix\x2dexport.mount: Deactivated successfully.
Jul 29 01:15:57 EVA-01 sudo[25884]:     root : TTY=pts/3 ; PWD=/home/engdyn/.cache/paru/clone/libretro-wasm4-git ; USER=engdyn ; COMMAND=/usr/bin/env SRCDEST=/home/engdyn/.cache/paru/clone/libretro-wasm4-git BUILDDIR=/tmp/makechrootpkg.kupmx39EL1 makepkg --config=/var/lib/archbuild/extra-x86_64/engdyn-1/etc/makepkg.conf --verifysource -o
Jul 29 01:15:57 EVA-01 sudo[25884]: pam_unix(sudo:session): session opened for user engdyn(uid=1000) by engdyn(uid=0)
Jul 29 01:15:59 EVA-01 sudo[25884]: pam_unix(sudo:session): session closed for user engdyn
Jul 29 01:15:59 EVA-01 sudo[27348]:     root : TTY=pts/3 ; PWD=/home/engdyn/.cache/paru/clone/libretro-wasm4-git ; USER=engdyn ; COMMAND=/usr/bin/bash -c '#012#011#011source PKGBUILD#012#011#011printf "%s\\n" "${pkgbase:-${pkgname}}" "${pkgname[@]}"#012'
Jul 29 01:15:59 EVA-01 sudo[27348]: pam_unix(sudo:session): session opened for user engdyn(uid=1000) by engdyn(uid=0)
Jul 29 01:15:59 EVA-01 sudo[27348]: pam_unix(sudo:session): session closed for user engdyn
Jul 29 01:16:00 EVA-01 systemd[1]: Started Container makechrootpkg-libretro-wasm4-git.build.25752.
Jul 29 01:16:08 EVA-01 kernel: ld-linux-x86-64[31150]: segfault at b8 ip 00007f404f8afb1b sp 00007ffecb349128 error 4 in libc.so.6[afb1b,7f404f824000+178000] likely on CPU 1 (core 1, socket 0)
Jul 29 01:16:08 EVA-01 kernel: Code: 85 e4 74 e7 4c 89 e2 4c 89 ef ff 15 07 64 16 00 43 c6 44 25 ff 00 eb d3 0f 1f 80 00 00 00 00 f3 0f 1e fa 48 8b 05 05 63 16 00 <8b> 90 b8 00 00 00 89 d1 f7 d1 81 e1 28 01 00 00 74 0b 48 8d 05 1c
Jul 29 01:16:08 EVA-01 systemd-coredump[31151]: Process 31150 (ld-linux-x86-64) of user 1000 terminated abnormally with signal 11/SEGV, processing...
Jul 29 01:16:08 EVA-01 systemd[1]: Started Process Core Dump (PID 31151/UID 0).
Jul 29 01:16:09 EVA-01 systemd[1]: Started Pass systemd-coredump journal entries to relevant user for potential DrKonqi handling.
Jul 29 01:16:09 EVA-01 systemd-coredump[31152]: Resource limits disable core dumping for process 31150 (ld-linux-x86-64).
Jul 29 01:16:09 EVA-01 systemd-coredump[31152]: [?] Process 31150 (ld-linux-x86-64) of user 1000 terminated abnormally without generating a coredump.
Jul 29 01:16:09 EVA-01 systemd[1]: systemd-coredump@3-20481-31151_45695-0.service: Deactivated successfully.
Jul 29 01:16:09 EVA-01 drkonqi-coredump-processor[31153]: Entry doesn't look like a dump. This may have been a vaccum run. Nothing to process.
Jul 29 01:16:09 EVA-01 drkonqi-coredump-processor[31153]: "/usr/lib/ld-linux-x86-64.so.2" 31150 ""
Jul 29 01:16:09 EVA-01 systemd[1]: drkonqi-coredump-processor@3-20481-31151_45695-0.service: Deactivated successfully.
Jul 29 01:16:09 EVA-01 systemd[1071]: Started Launch DrKonqi for a systemd-coredump crash (PID 31153/UID 0).
Jul 29 01:16:09 EVA-01 systemd[1]: makechrootpkg-libretro-wasm4-git.build.25752.scope: Deactivated successfully.
Jul 29 01:16:09 EVA-01 systemd[1]: makechrootpkg-libretro-wasm4-git.build.25752.scope: Consumed 10.735s CPU time over 8.260s wall clock time, 709.3M memory peak.
Jul 29 01:16:09 EVA-01 drkonqi-coredump-launcher[31160]: Unable to find file for pid 31150 expected at "kcrash-metadata/ld-linux-x86-64.so.2.9086bc88c4af46bdb583419a17b0a8d9.31150.ini"
Jul 29 01:16:09 EVA-01 drkonqi-coredump-launcher[31160]: KCrash metadata not marked complete. Please file a bug at bugs.kde.org giving as much detail about the crash as possible and maybe include the file ""
Jul 29 01:16:09 EVA-01 systemd[1]: run-systemd-nspawn-makechrootpkg\x2dlibretro\x2dwasm4\x2dgit.build.25752-unix\x2dexport.mount: Deactivated successfully.
Jul 29 01:16:09 EVA-01 sudo[25729]: pam_unix(sudo:session): session closed for user root

I rebooted into a snapshot and restored it. I tried to recompile it outside the chroot and had the same result. I tried running my wasm4 core again (the one before I recompiled it) and it works fine. I checked paclog and I compiled it on the 10th of July with gcc 16.1.1+r346+g4e03491b401d-1. So this seems to be the last working version.
I wrote the PKGBUILD myself and it's in the AUR. I also tried running "pkgctl build" with other PKGBUILDs from completely different projects and every time ld-linux-x86-64 segfaults. I'm using the default kernel.

I honestly have no idea what I should try or do. The moment gcc or (dynamic) linker breaks my brain turns off. Any help to isolate the problem and/or fix it would be much appreciated.

Last edited by Engdyn (2026-08-16 07:09:15)

seth · 2026-07-29 06:44:14

glibc updated to 2.44 on July 25th and gcc was rebuild for that - assuming you're not holding back any versions, does moving back in time to before that fix things?
https://wiki.archlinux.org/title/Arch_L … cific_date
libretro/retroarch might require a rebuild, no idea whether building wasm4 using gcc15 would (still) work

Lone_Wolf · 2026-07-29 09:31:48

On july 25 there was a toolchain rebuild for glibc 2.44 , on july 28 there was another toolchain rebuild for binutils 2.47 .

You need to check atleast 2 dates : one before july 25 and one between july 25 and july 28 .

Engdyn · 2026-07-30 09:36:10

I tried some different dates and it didn't help. I investigated a bit more and it's actually 2 different problems that I coincidentally encountered at the same time.

The first problem was an update to a submodule of the wasm4 core that caused the segfault. I submitted an upstream PR that got merged and it's working fine again.

The other problem is isolated to "pkgctl". I setup a VM with a minimal arch install to make sure it's not my install and it's happening there too. The dynamic linker segaults when building a package with "pkgctl build", but only the debug part.
If we take libretro-wasm4-git as an example, if you use "makepkg" you'll get, without any issues, libretro-wasm4-git-version.tar.zst and libretro-wasm4-git-debug-version.tar.zst. If you use "pkgctl build" instead, you'll get libretro-wasm4-git-version.tar.zst but not libretro-wasm4-git-debug-version.tar.zst because the dynamic linker segfaults while trying to build it.

I'm unsure where I should report it. The dynamic linker is part of gcc, but it only segfaults when using "pkgctl". Should I report this to the gcc or devtools package on the arch gitlab?

seth · 2026-07-30 11:56:37

https://wiki.archlinux.org/title/Core_d … _core_dump
https://wiki.archlinux.org/title/Debuginfod
What does the linker segfault actually look like?

Engdyn · 2026-07-30 16:35:37

That's kinda the issue. There's no core dump and I don't know how to get one. Something disables the core dumps for the chroot as far as I understand.

That's what I have in my journal every time.

Jul 30 18:23:56 EVA-01 systemd-coredump[174568]: Process 174567 (ld-linux-x86-64) of user 1000 terminated abnormally with signal 11/SEGV, processing...
Jul 30 18:23:56 EVA-01 systemd[1]: Started Process Core Dump (PID 174568/UID 0).
Jul 30 18:23:56 EVA-01 systemd[1]: Started Pass systemd-coredump journal entries to relevant user for potential DrKonqi handling.
Jul 30 18:23:56 EVA-01 systemd-coredump[174569]: Resource limits disable core dumping for process 174567 (ld-linux-x86-64).
Jul 30 18:23:56 EVA-01 systemd-coredump[174569]: [?] Process 174567 (ld-linux-x86-64) of user 1000 terminated abnormally without generating a coredump.

I tried to get something with strace and the last thing before it segfaults is "Relink with libc.so.6 for IFUNC symbol strlen". Here's the complete strace of the child process:

set_robust_list(0x7f330bd31e60, 24)     = 0
rt_sigprocmask(SIG_SETMASK, [INT TERM CHLD], NULL, 8) = 0
getpid()                                = 3736
rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0
rt_sigaction(SIGTSTP, {sa_handler=SIG_DFL, sa_mask=[], sa_flags=SA_RESTORER, sa_restorer=0x7f330ba3e6f0}, {sa_handler=SIG_DFL, sa_mask=[], sa_flags=SA_RESTORER, sa_restorer=0x7f330ba3e6f0}, 8) = 0
rt_sigaction(SIGTTIN, {sa_handler=SIG_DFL, sa_mask=[], sa_flags=SA_RESTORER, sa_restorer=0x7f330ba3e6f0}, {sa_handler=SIG_DFL, sa_mask=[], sa_flags=SA_RESTORER, sa_restorer=0x7f330ba3e6f0}, 8) = 0
rt_sigaction(SIGTTOU, {sa_handler=SIG_DFL, sa_mask=[], sa_flags=SA_RESTORER, sa_restorer=0x7f330ba3e6f0}, {sa_handler=SIG_DFL, sa_mask=[], sa_flags=SA_RESTORER, sa_restorer=0x7f330ba3e6f0}, 8) = 0
rt_sigaction(SIGINT, {sa_handler=SIG_DFL, sa_mask=[], sa_flags=SA_RESTORER, sa_restorer=0x7f330ba3e6f0}, {sa_handler=0x55a750699b70, sa_mask=[], sa_flags=SA_RESTORER, sa_restorer=0x7f330ba3e6f0}, 8) = 0
rt_sigaction(SIGQUIT, {sa_handler=SIG_DFL, sa_mask=[], sa_flags=SA_RESTORER, sa_restorer=0x7f330ba3e6f0}, {sa_handler=SIG_DFL, sa_mask=[], sa_flags=SA_RESTORER, sa_restorer=0x7f330ba3e6f0}, 8) = 0
rt_sigaction(SIGCHLD, {sa_handler=SIG_DFL, sa_mask=[], sa_flags=SA_RESTORER|SA_RESTART, sa_restorer=0x7f330ba3e6f0}, {sa_handler=0x55a75066e240, sa_mask=[], sa_flags=SA_RESTORER|SA_RESTART, sa_restorer=0x7f330ba3e6f0}, 8) = 0
execve("/usr/lib64/ld-linux-x86-64.so.2", ["/usr/lib64/ld-linux-x86-64.so.2", "/tmp/tmphji3ftoa"], 0x55a77dc64b10 /* 9 vars */) = 0
newfstatat(AT_FDCWD, "/etc/ld.so.cache", {st_mode=S_IFREG|0644, st_size=26151, ...}, 0) = 0
openat(AT_FDCWD, "/etc/ld.so.cache", O_RDONLY|O_CLOEXEC) = 3
fstat(3, {st_mode=S_IFREG|0644, st_size=26151, ...}) = 0
mmap(NULL, 26151, PROT_READ, MAP_PRIVATE, 3, 0) = 0x7f3f97791000
close(3)                                = 0
brk(NULL)                               = 0x555557cc3000
openat(AT_FDCWD, "/tmp/tmphji3ftoa", O_RDONLY|O_CLOEXEC) = 3
read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\0\0\0\0\0\0\0\0"..., 1024) = 1024
readlinkat(AT_FDCWD, "/proc/self/fd/3", "/tmp/tmphji3ftoa", 4095) = 16
mmap(NULL, 262672, PROT_READ, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x7f3f97750000
mmap(0x7f3f97752000, 102400, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x2000) = 0x7f3f97752000
mmap(0x7f3f9776b000, 28672, PROT_READ, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x1b000) = 0x7f3f9776b000
mmap(0x7f3f97772000, 20480, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x22000) = 0x7f3f97772000
mmap(0x7f3f97777000, 102928, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x7f3f97777000
close(3)                                = 0
mmap(NULL, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f3f9774e000
access("/etc/ld.so.preload", R_OK)      = -1 ENOENT (No such file or directory)
newfstatat(AT_FDCWD, "/etc/ld.so.cache", {st_mode=S_IFREG|0644, st_size=26151, ...}, 0) = 0
openat(AT_FDCWD, "/usr/lib/libc.so.6", O_RDONLY|O_CLOEXEC) = 3
read(3, "\177ELF\2\1\1\3\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\300y\2\0\0\0\0\0"..., 1024) = 1024
fstat(3, {st_mode=S_IFREG|0755, st_size=2202784, ...}) = 0
mmap(NULL, 2227024, PROT_READ, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x7f3f97400000
mmap(0x7f3f97424000, 1540096, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x24000) = 0x7f3f97424000
mmap(0x7f3f9759c000, 483328, PROT_READ, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x19c000) = 0x7f3f9759c000
mmap(0x7f3f97612000, 24576, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x211000) = 0x7f3f97612000
mmap(0x7f3f97618000, 31568, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x7f3f97618000
close(3)                                = 0
mmap(NULL, 12288, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f3f9774b000
arch_prctl(ARCH_SET_FS, 0x7f3f9774b740) = 0
set_tid_address(0x7f3f9774bd68)         = 3736
set_robust_list(0x7f3f9774ba20, 24)     = 0
rseq({cpu_id_start=0, cpu_id=RSEQ_CPU_ID_UNINITIALIZED, rseq_cs=NULL, flags=0, node_id=0, mm_cid=0, slice_ctrl={request=0, granted=0, __reserved=0}, __reserved=0}, 33, 0, 0x53053053) = 0
getrandom("\x25\x0d\x68\x9c\x21\x9f\x96\xaf\x56\x94\x6c\xc8\xb2\x96\x0e\x4d", 16, GRND_NONBLOCK) = 16
writev(2, [{iov_base="/tmp/tmphji3ftoa", iov_len=16}, {iov_base=": Relink `", iov_len=10}, {iov_base="", iov_len=0}, {iov_base="' with `", iov_len=8}, {iov_base="/usr/lib/libc.so.6", iov_len=18}, {iov_base="' for IFUNC symbol `", iov_len=20}, {iov_base="strlen", iov_len=6}, {iov_base="'\n", iov_len=2}], 8) = 80
--- SIGSEGV {si_signo=SIGSEGV, si_code=SEGV_MAPERR, si_addr=0xb8} ---
+++ killed by SIGSEGV (core dumped) +++

The number of segfaults varies too. I built RetroArch with the PKGBUILD from the Arch Linux gitlab and it had 11 segfaults.

TIME                            PID  UID  GID SIG     COREFILE EXE                           SIZE
Thu 2026-07-30 18:23:55 CEST 174279 1000 1000 SIGSEGV none     /usr/lib/ld-linux-x86-64.so.2    -
Thu 2026-07-30 18:23:55 CEST 174307 1000 1000 SIGSEGV none     /usr/lib/ld-linux-x86-64.so.2    -
Thu 2026-07-30 18:23:55 CEST 174323 1000 1000 SIGSEGV none     /usr/lib/ld-linux-x86-64.so.2    -
Thu 2026-07-30 18:23:55 CEST 174347 1000 1000 SIGSEGV none     /usr/lib/ld-linux-x86-64.so.2    -
Thu 2026-07-30 18:23:55 CEST 174363 1000 1000 SIGSEGV none     /usr/lib/ld-linux-x86-64.so.2    -
Thu 2026-07-30 18:23:55 CEST 174386 1000 1000 SIGSEGV none     /usr/lib/ld-linux-x86-64.so.2    -
Thu 2026-07-30 18:23:56 CEST 174485 1000 1000 SIGSEGV none     /usr/lib/ld-linux-x86-64.so.2    -
Thu 2026-07-30 18:23:56 CEST 174498 1000 1000 SIGSEGV none     /usr/lib/ld-linux-x86-64.so.2    -
Thu 2026-07-30 18:23:56 CEST 174541 1000 1000 SIGSEGV none     /usr/lib/ld-linux-x86-64.so.2    -
Thu 2026-07-30 18:23:56 CEST 174554 1000 1000 SIGSEGV none     /usr/lib/ld-linux-x86-64.so.2    -
Thu 2026-07-30 18:23:56 CEST 174567 1000 1000 SIGSEGV none     /usr/lib/ld-linux-x86-64.so.2    -

The thing is everything does work in the end. It's just odd that it's segfaulting.

seth · 2026-07-30 18:32:04

Jul 29 01:16:09 EVA-01 systemd-coredump[31152]: Resource limits disable core dumping for process 31150 (ld-linux-x86-64).

Do you do any of https://wiki.archlinux.org/title/Core_d … core_dumps or do segfaults outside the chroot/pkgctl usage get stored?

Either way, try to "export VERBOSE=1", the message lacks the subject - it's supposed to be "Relink <foo> with libc.so.6 for IFUNC symbol strlen"
<foo> seems to be "/tmp/tmphji3ftoa" (name being random) - can you preserve that file and/or inspect it w/ ldd (notably whether it claims to be statically linked)?
Do you get this building everything w/ pkgctl or only retroarch?

Engdyn · 2026-07-30 19:15:06

No I didn't disable anything. I'm getting core dumps for everything except stuff that's happening inside the pkgctl chroot.
I don't think I can preserve the file but I can try tomorrow together with the other thing.

This issue is 100% reproducible on every machine that is running an up to date version of Arch Linux and it's happening with every PKGBUILD that exists. It's happening on my machine, in a VM, on my laptop and on the machine of a friend of mine. That's not just my pc doing something weird.

seth · 2026-07-30 19:36:24

https://man.archlinux.org/man/pkgctl-build.1

Does "pkgctl build -c <randompackagenottretroarch>" cause this?
"--inspect always" shall allow you to inspect the chroot (if this is a global issue I'd expect some of the main package maintainers would have filed bugs by now)

loqs · 2026-07-30 22:25:57

I have hundreds of occurrences from rebuilds related to OpenSSL 4 with the first occurrence being just before midnight on Sunday the 26th. seth maintainers might not have noticed as nothing is present on screen or in the build logs.
Edit:
seth can you reproduce with the small package bzip2?

Last edited by loqs (2026-07-30 22:29:16)

seth · 2026-07-31 06:57:08

seth will hav to update and install devtools first, but

just before midnight on Sunday the 26th

seth wrote:

glibc updated to 2.44 on July 25th and gcc was rebuild for that

https://sourceware.org/bugzilla/show_bug.cgi?id=34428
Semi-related, https://sourceware.org/bugzilla/show_bug.cgi?id=34429

Unfortunately sourceware.org/git/glibc.git seems to struggle a bit but https://inbox.sourceware.org/libc-annou … too.org/T/ has a bunch of IFUNC related patches to I bet everyones right arm on the glibc regression (not mine, though. I'll still need that one)

---
https://sourceware.org/git/?p=glibc.git … f15d83d0f1
https://sourceware.org/git/?p=glibc.git … 3fc569bfa6

Those are massive re-orders of the ifunc resolution and probably something related to chroot, debug compiler settings or pkgctl specific will run into a gap here, but apparently checking for unused symbols is enough - and reproducible here.

Last edited by seth (2026-07-31 14:15:03)

Toolybird · 2026-08-01 22:10:42

> I have hundreds of occurrences

@loqs, me too. A quick bit of investigation reveals the trigger is namcap. I've created a ticket to raise awareness:

https://gitlab.archlinux.org/archlinux/ … k_items/26

Last edited by Toolybird (2026-08-01 22:11:03)

Arch Linux

#1 2026-07-29 00:38:47

[SOLVED] Dynamic linker is segfaulting

#2 2026-07-29 06:44:14

Re: [SOLVED] Dynamic linker is segfaulting

#3 2026-07-29 09:31:48

Re: [SOLVED] Dynamic linker is segfaulting

#4 2026-07-30 09:36:10

Re: [SOLVED] Dynamic linker is segfaulting

#5 2026-07-30 11:56:37

Re: [SOLVED] Dynamic linker is segfaulting

#6 2026-07-30 16:35:37

Re: [SOLVED] Dynamic linker is segfaulting

#7 2026-07-30 18:32:04

Re: [SOLVED] Dynamic linker is segfaulting

#8 2026-07-30 19:15:06

Re: [SOLVED] Dynamic linker is segfaulting

#9 2026-07-30 19:36:24

Re: [SOLVED] Dynamic linker is segfaulting

#10 2026-07-30 22:25:57

Re: [SOLVED] Dynamic linker is segfaulting

#11 2026-07-31 06:57:08

Re: [SOLVED] Dynamic linker is segfaulting

#12 2026-08-01 22:10:42

Re: [SOLVED] Dynamic linker is segfaulting

Board footer