zentara wrote:
tabanna wrote:
Hi SuSErs :)
What does "SO" imply, as in ~ ~ ld.so.cache ?
Thanks
I believe it's "Shared Object" as opposed to a static object file. It's a way of having 1 instance of a library shared between more than 1 running application. Old static libs have .o endings.
Zentara, Indeed "Shared Object" is correct. They are, what have been know in the industry for quite some time as, dynamically linked libraries or DLLs. When Microsoft build Windows NT they used the extention DLL for their shared objects. So basically SOs are DLLs. "Static" actually refers to the way they objects are linked. When you compile and link a program you may use some code that could be used by other programs as well. The compiler turns your source code into .o object files. The linker then builds a file consisting of all the object files created by the compiler. When the code is execute the CPU needs to know what locaton in memory it needs to access to read its instructions. The linker provides a mapping to the starting points of the functions in the object files. If the linker creates one monolithic file with all the objects contained therein, that is called static linking. It is possible - and often done - to link to objects contained in files external to the product of the current linking process. If you look in you /lib or /usr/lib or /usr/local/lib or .... you will see a bunch of library files. Try running `nm /lib/ld-2.1.3.so', or `nm' on any *.so. I believe the output of this is a way of mapping functon names to relative adress locations for the function entry points. When you write code you often put the names of libraries in header files, <filename>.h files. These files tell the linker where to find the library files needed to specify the branch points to external library files. When you download sorce code and build it yourself, you usually run ./config(ure) which is a standard type of script which traverses the source tree and creates the platform specific makefiles for your build. then you run `make' which first compiles all the <filename>.c files into <filename>.o files. After that the linking process takes place. This is done by the `ld' command. What the `make' command does is traverse the source tree executing all the makefile "scripts"; once for the compilation of the source code into object code using gcc; then once to link the object files into executable code or libraries using ld. If you watch this process you will see a bunch of stuff like: make[2]: Entering directory `/usr/src/kde/qt-copy/src/moc' g++ -c -I/usr/src/kde/qt-copy/include -Wno-unused -Wno-parentheses -pipe -O2 -DQT_NO_CODECS -DQT_LITE_UNICODE -I../../include -I../tools -I. -o mocgen.o mocgen.cpp g++ -c -I/usr/src/kde/qt-copy/include -Wno-unused -Wno-parentheses -pipe -O2 -DQT_NO_CODECS -DQT_LITE_UNICODE -I../../include -I../tools -I. -o qbuffer.o ../tools/qbuffer.cpp g++ -c -I/usr/src/kde/qt-copy/include -Wno-unused -Wno-parentheses -pipe -O2 -DQT_NO_CODECS -DQT_LITE_UNICODE -I../../include -I../tools -I. -o qcollection.o ../tools/qcollection.cpp ../tools/qcollection.cpp: In method `void QCollection::deleteItem(void *)': ../tools/qcollection.cpp:170: warning: `void *' is not a pointer-to-object type g++ -c -I/usr/src/kde/qt-copy/include -Wno-unused -Wno-parentheses -pipe -O2 -DQT_NO_CODECS -DQT_LITE_UNICODE -I../../include -I../tools -I. -o qcstring.o ../tools/qcstring.cpp As you can see, make first enters the /src/moc directory. Then it runs `g++' which is the c++ mode of gcc. All the stuff after the g++, such as -c -I/usr/src/kde/qt-copy/include -Wno-unused -Wno-parentheses are options for g++ which are stated in the makefiles. after several minutes of running you may see something like this: g++ -c -I/usr/src/kde/qt-copy/include -I/usr/X11R6/include -pipe -O2 -fPIC -DQT_BUILTIN_GIF_READER=0 -DQT_NO_IMAGEIO_JPEG -I/usr/src/kde/qt-copy/src/3rdparty/zlib -I/usr/src/kde/qt-copy/src/3rdparty/libpng -I/usr/X11R6/include -o kernel/qpsprinter.o kernel/qpsprinter.cpp /usr/src/kde/qt-copy/include/qintdict.h: In method `void QIntDict<void>::deleteItem(void *)': kernel/qpsprinter.cpp:3337: instantiated from here /usr/src/kde/qt-copy/include/qintdict.h:72: warning: `void *' is not a pointer-to-object type /usr/src/kde/qt-copy/bin/moc kernel/qthread_unix.cpp -o kernel/qthread_unix.moc BUG IN DYNAMIC LINKER ld.so: dl-version.c: 210: _dl_check_map_versions: Assertion `needed != ((void *)0)' failed! make[2]: *** [kernel/qthread_unix.moc] Error 127 make[2]: Leaving directory `/usr/src/kde/qt-copy/src' make[1]: *** [src] Error 2 make[1]: Leaving directory `/usr/src/kde/qt-copy' make: *** [init] Error 2 honuman:/usr/src/kde/qt-copy # At this point you pickup your keyboard and slam it down while b!tching that THE SuSE FOLKS NEED TO GET THE FREAKIN' UPDATED RPMs ON THEIR FREAKING SITE!!!!!!!!!!!!!!! Then you send off this email realizing they are doing what they can, and there are reasons SuSE 7 is taking longer than expected to ship in the states. I believe they are doing it just to BSAFE. If you build again after one build attempt whithout running make clean first, you will see messages like these: ... make[2]: Entering directory `/usr/src/kde/qt-copy/src/moc' make[2]: Nothing to be done for `all'. make[2]: Leaving directory `/usr/src/kde/qt-copy/src/moc' rm -f bin/moc cp src/moc/moc bin/moc make -f src-mt.mk make[2]: Entering directory `/usr/src/kde/qt-copy' (not building threaded Qt) make[2]: Leaving directory `/usr/src/kde/qt-copy' cd src; make make[2]: Entering directory `/usr/src/kde/qt-copy/src' /usr/src/kde/qt-copy/bin/moc kernel/qthread_unix.cpp -o kernel/qthread_unix.moc BUG IN DYNAMIC LINKER ld.so: dl-version.c: 210: _dl_check_map_versions: Assertion `needed != ((void *)0)' failed! make[2]: *** [kernel/qthread_unix.moc] Error 127 make[2]: Leaving directory `/usr/src/kde/qt-copy/src' make[1]: *** [src] Error 2 make[1]: Leaving directory `/usr/src/kde/qt-copy' make: *** [init] Error 2 honuman:/usr/src/kde/qt-copy # As you can see, g++ had "Nothing to be done for `all'." This is because `make' found object files in the directory from the last build. The error I'm getting seems to indicate the "dynamic linker" is out dated. The dynamic loader, AKA ld.so, is the library responsible for providing access to the other shared object libraries when a program executes. Traditionally an LD_LIBRARY_PATH was used to tell the ld.so where to find libraries. Linux uses a nifty feature which allows a nicer configuration and better performance. It builds an ld.so.cache at boot time. It finds out where to find libraries by looking in the /etc/ld.so.conf. If you add new libraries to your system, you can add a path to them in the /etc/ld.so.conf and run ld.config [-v]. This rebuilds the ld.so.cache to include the new libraries. Oh will, I really don't know how much of this is correct. I've just kind of obsorbed this stuff over the past three years. HTH, Steve -- For a look at the future click below: http://www.suse.com || http://www.linuxbase.org http://www.kde.org || http://samba.anu.edu.au http://www.winehq.com || http://www.mozilla.org -- To unsubscribe send e-mail to suse-linux-e-unsubscribe@suse.com For additional commands send e-mail to suse-linux-e-help@suse.com Also check the FAQ at http://www.suse.com/support/faq