On 05/26/2018 06:36 AM, Philipp Kern wrote: > If you link statically or if you use very few 32-bit programs on a > 64-bit system you actually waste memory by having the library code > duplicated in memory.
That's what they tell me. But going whole-hog with shared libs introduces another dependency hell. (Don't we have enough of those already?) You can't ship your pre-compiled program without indicating a number of co-reqs at the installation end. That, or ship whatever versions of the requisite .so files you built against. For a long time I took a hybrid approach. I built executables with GLIBC shared (because it's far and away the most significant part, and the most significant memory savings) but all /other/ support libraries linked statically. Worked really well! GLIBC was guaranteed to be there (until Alpine). More recently, I'm going totally static for most things. Call it an experiment. Call it a hobby. I'm feeling out what works and what doesn't ... and what minimizes pain for me and for my customers. Alpine Linux challenges the traditional shared library wisdom (or did). They link everything statically (or did). But Alpine varies two things: First they use Musl instead of GLIBC, which is significantly smaller from the get-go. Second, Alpine is very BusyBox-centric, which goes a totally different "sharing" route. Even so, when I first investigated Alpine, things were all statically linked. Sans GLIBC, I found that my pre-compiled packages didn't run on Alpine. Even reducing the shared reqs to "the runtime", when the runtime itself changed I was stuck. This would be true for other distros (witness Arch Linux or any which use uClibc). As for me, I came to dislike shared libraries from repeated pain with LOADLIBs in CMS. Found that things went much more smoothly if I linked against TXTLIBs instead. I hate having to add various LOADLIBs to the search. Things are slightly easier with Linux (because the loader searches /usr/lib and/or /usr/lib64 and others by default.) Even on Linux, if I bring in an executable with some req for some foreign shared library, I'm SOL unless I snag that lib and set LD_LIBRARY_PATH to find it. But this is mostly a matter of taste. I AM NOT saying shared libraries are inherently bad, merely challenging presumption that they're intrinsically right. -- R; <>< ---------------------------------------------------------------------- For LINUX-390 subscribe / signoff / archive access instructions, send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390 ---------------------------------------------------------------------- For more information on Linux on System z, visit http://wiki.linuxvm.org/
