Re:“Shared libraries are not a good thing in general”
by higerordermap on Sunday May 02, 2021 @02:17AM
(#27012758)
> Well, you could, if you could rely on LD_LIBRARY_PATH to be set to "." by default.
It's actually supported without LD_LIBRARY_PATH hacks, using DT_RPATH. You can do that by passing -rpath '$ORIGIN' to linker IIRC.
Re:“Shared libraries are not a good thing in general”
by TeMPOraL on Sunday May 02, 2021 @05:03AM
(#27013544)
Thanks! I forgot all about it, in particular about '$ORIGIN' thing! Yes, I'm happy to see the person building the executable has at least some control over this.
It's actually relevant to a project I'm working on (proprietary, Windows/Linux, uses shared libraries for both mandatory components and optional plugins) - I'm gonna check if and how we're setting RPATH for the Linux builds, it might need some tweaking.
Or put in a different way: the problem is the "shared" part, not the "dynamic linking" part. Instead of static linking, you can avoid the issue of library versions by just shipping your shared libraries along with your program[0] - and this way, users still retain the ability to swap out components if the need arises.
--
[0] - Well, you could, if you could rely on LD_LIBRARY_PATH to be set to "." by default. Windows is doing it right, IMO, by prioritizing program location over system folders when searching for DLLs to load.