jablkoziemne
lambdageekI take back everything bad I said about rpaths and sonames.
Turns out LoadLibraryExW is like 1000 times worse
#sharedLibraries #dynamicLinking #softwareEngineering #win32 #winapi #dlls
@unix_discussions Why they compared tge size of the executable file, with the size of #flatpak package? Shouldnt we at least try to include for standard #linux #package all #dependencies it requires or at lest compare #staticlinking with their flatpak counterparts to get rough estimate of flatpak metadata size overhead, and dependency duplication from runtime and separately whatever was put alongside the contenerized application. Also, it would be cool to compare it across many #linuxdistribution in case there are some that due to #dynamiclinking have to bundle multiple versions of given library
sonames and rpaths can go fuck themselves
Periodic reminder that static libraries on literally every major platform is just 1970's era 'ar' archives of object files and are not a real module system.
This post brought to you by stupid duplicate symbols linker errors even though I'm using `--exclude-libs` and `-hidden-lx` and every linker flag I can think of. Because it's all just terrible.
Can we just make the WASM Component Model the default for everything already
Sergei TrofimovichTIL use of gnulib's obstack API on glibc systems adds exported dynamic symbols to final binaries (normally harmless but somewhat unusual thing for programs that don't load plugins).
Even '/bin/ls' has a few of those exported out of a binary:
$ nm -D `which ls` | grep -v '^ '
00000000004c0d40 T _obstack_allocated_p
0000000000534808 D obstack_alloc_failed_handler
00000000004c0bd0 T
...
https://lists.gnu.org/archive/html/bug-gnulib/2022-12/msg00121.html