Shared libraries

I was reading 6.1 Introduction, and was linked to BLFS ch 2 "Libraries: Static or shared?". In it,

Within the book, there are various places where configure switches such as --disable-static are employed, and other places where the possibility of using system versions of libraries instead of the versions included within another package is discussed. The main reason for this is to simplify updates of libraries.

Does this mean that when --disable-static is used, the corresponding package uses the libraries from other packages?

What are system versions of libraries?
Are they installed when the OS is installed, the libs for the OS to run properly?

Where are the lib versions from other packages installed?
Will there not be a conflict if these packages and system packages are same libs with only differents versions?

Are shared libraries, used to minimize memory and simplify update of libraries?

Programs use libraries either dynamically or statically. When a program uses a dynamic library, the OS loads it into memory and tells the program where to access it. When a program uses a library statically the routine the program calls gets built into the program at compilation. Thus a program built with static libraries is usually much larger on disk, and in RAM when running. A dynamic library only has to be loaded once: all programs that call it use the same instance. One may want to build a program statically if it may be used when the dynamic libraries aren't available, as may happen when there's a problem with a disk.

Here, do they mean that when --disable-static is used, the corresponding package uses the libraries from other packages?

disable static is a link time option, it means the given app should use dynamic libraries (.so files) instead of their static counterparts.
But it is a link time option, you specify it during the build of the application.
When you run that app it will look for these .so files (libraries) and will try to use them (if found). The app does not really care about the question "where are these libraries coming from". So yes, probably they are part of other packages, or whatever. It depends on the maintainer of that host.

So, the libraries that were installed for the OS(system libraries) and libraries of other packages are all heaped up in one dir(/lib) and it's subdirectories, for use?

this is more or less true (but a bit simplified). Libraries - in general - are used by apps and they are stored in /lib (or a similar dir) to be able to use them. Not for the OS, for any app which needs.
You can imagine, a library contains some features, if an app wanted to use those features need to use that lib (that's why they are shared).
wiki shared libraries

Since you are talking about LFS, some of the answers given here are not entirely relevant.

The term "system libraries" usually means libraries that are already on the system, which a new package can link to. Some packages (notably Firefox) come with their own versions of these libraries, allowing unprivileged users to install them under their own directories and have everything they need to run the program guaranteed to be at hand whether the libraries are on the system or not. But this is not the normal way that Linux does things.

System libraries are installed from separate packages. Each commonly-used library comes in a package of its own; once it is installed, any program that needs it can link to it. In binary distros you can study this by using a graphical package manager like Debian's synaptic. You can see that there are library packages and application packages.

A complicating factor in LFS is that everything is built locally. This means that packages which have their own internal versions of certain libraries have to be told during the build whether to use these versions or the system versions. Usually the latter is preferable, as built-in libraries are often poorly maintained and contain security flaws. But sometimes the build can't use any version of a particular library other than the one it came with. Firefox is increasingly incompatible with external libraries. There was some recent correspondence about this on the lfs-dev mailing list.

See: https://www.linuxquestions.org/quest...ed-them-37743/

A dynamically-linked program looks in the libraries pointed to by /etc/ld.so.cache. ld.so.cache points to all the libraries in the directories in /etc/ld.so.conf after ldconfig runs. Slackware's start-up includes running ldconfig. If I build a new library, after I install it, I have to run ldconfig for a program to use it. If I create a new directory of libraries I have to add it to ld.co.conf. Build a program with static linking, then build it with dynamic linking, compare the size.

If it's a diagnostic or repair program you want to work even if a problem causes dynamic libraries to be unavailable you want it statically linked.

Most makefiles for building libraries include the ldconfig command as part of the install target, so you don't necessarily need to run it yourself. But it does need to be run somehow.