3 ms·
On the flip side of that, Win32 also includes the local directory near the start of the LoadLibrary search path. The result being that a lot of applications bun
by tonyarkles 6y ago
On the flip side of that, Win32 also includes the local directory near the start of the LoadLibrary search path. The result being that a lot of applications bundle all of their own dependencies when there are already 15 copies installed on the system. In some cases I’m good with that, in others it’s a pretty big waste of space compared to having a system with an easily configurable versioned shared library repository.
- ascagnel_ 6y agoOne side effect of this is users can use patched DLLs for compatibility or to add new features (this is how tools like ReShade work).
- tannhaeuser 6y agoHmm I think shared lib loading on Mac OS isn't supposed to work like that. DYLD_LIBRARY_PATH is only a method of last resort; normally, an app should have any lib path baked in (where the baked in path can be relative, and can also contain variables as path steps). At link-time, the linker picks up the install name of any shared libs needed, and bakes these into the executable. I find this to be a saner model than on Linux where an executable can't have an RPATH (only a shared lib can). Actually, it seems the whole concept of shared libraries might be more trouble than worth, especially on F/OSS operating systems; on Linux, there's a whole cottage industry based on the problem of shared libs not being uniform across versions and distros (ie Docker).
- badsectoracula 6y agoApplications on Linux also do that often when they are released in binary form (especially closed source software) outside of some repository, they just use a shell script to add the current directory (or a subdirectory) to the library search path before starting the executable.