wrong description
In the file /kde/core/kdebase.xml at line 163 and following i found this description: kdeprint is a dialog box for managing diagnostic messages at runtime. Maybe is better the one from the KDE website, like: "KDEPrint is the printing module in KDE. It manages the actual printing from KDE applications, handles print job administration and handles printer and print system management" At line 237 in the description of "kioslaves" there is "certian" instead of "certain" Giulio -- ++ | LFS user #11031 | ++ -- Email.it, the professional e-mail, gratis per te: http://www.email.it/f Sponsor: Bisogno di liquidità? Non devi spiegare per cosa. Fino a 4.000 a casa tua Clicca qui: http://adv.email.it/cgi-bin/foclick.cgi?mid=2291&d=20050223 -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: wrong description
Giulio Daprelà wrote: In the file /kde/core/kdebase.xml at line 163 and following i found this description: kdeprint is a dialog box for managing diagnostic messages at runtime. Maybe is better the one from the KDE website, like: "KDEPrint is the printing module in KDE. It manages the actual printing from KDE applications, handles print job administration and handles printer and print system management" At line 237 in the description of "kioslaves" there is "certian" instead of "certain" Fixed. Thanks. It always helps to have more eyes spotting errors. -- Bruce -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: Linux-PAM nitpicks
Steve Crosby wrote: hmm... [EMAIL PROTECTED] /1]$ ldd /bin/sleep linux-gate.so.1 => (0xe000) libm.so.6 => /lib/libm.so.6 (0xb7fc5000) librt.so.1 => /lib/librt.so.1 (0xb7fbd000) libc.so.6 => /lib/libc.so.6 (0xb7eaf000) /lib/ld-linux.so.2 (0xb7fec000) libpthread.so.0 => /lib/libpthread.so.0 (0xb7e9d000) [EMAIL PROTECTED] /]$ ls -l /lib/libm* -rwxr-xr-x 1 root root 146040 Feb 11 20:48 /lib/libm-2.3.4.so lrwxrwxrwx 1 root root 13 Feb 11 22:14 /lib/libm.so.6 -> libm-2.3.4.so -rwxr-xr-x 1 root root 13724 Feb 11 20:48 /lib/libmemusage.so [EMAIL PROTECTED] /]$ file /lib/libm-2.3.4.so /lib/libm-2.3.4.so: ELF 32-bit LSB shared object, Intel 80386, version 1 (SYSV), stripped How does that gel with the paragraphs above? libm-2.3.4.so is the actual runtime library, not only the compile\linking library... -- - Steve Crosby The problem is here is just that Glibc is a bit weird with how they name their libraries for whatever reason. If you notice there is an "unversioned *.so symlink" in /usr/lib. On my system I get: /usr/lib/libm.so -> ../../lib/libm.so.6 So, things still work the same, just the naming is a bit off. Here's how I look at it: You go to compile something, it decides that it want's libm and starts off looking at /usr/lib to see what it can find. It comes across a file /usr/lib/libm.so which is linked to a file called /lib/libm.so.6. based on this it tells the linker to link the resulting binary to a file named /lib/libm.so.6. When you run the program it sees that it need to load up the file /lib/libm.so.6 and in doing so ends up following the symlink and ends up actually loading /lib/libm.2.3.4.so in the process. Some months later you decide to upgrade Glibc to version 2.3.5 (I'll make the assumption the 2.x.x versions are ABI compatible). so now you have: /usr/lib/libm.so -> ../../lib/libm.so.6 /lib/libm.so.6 -> libm.2.3.5.so /usr/libm.2.3.4.so (the old left over lib) /usr/libm.2.3.5.so (the newley installed lib) Now when we run the binary it will try to load /lib/libm.so.6 again, but this time, it ends up using libm.2.3.5.so instead, and libm.2.3.4.so just gets left by the way side.. Then, a while later you decide to install the brand new Glibc 3.0! (Glibc is probably a bad example cause Glibc 3.0 seems to me like something out of science fiction..) ..Now, you end up with this: /usr/lib/libm.so -> ../../lib/libm.so.7 /lib/libm.so.6 -> libm.2.3.5.so /lib/libm.so.7 -> libm.3.0.so (oooh this is new!) /usr/libm.2.3.4.so (now old and crusty) /usr/libm.2.3.5.so (also crusty) /lib/libm.3.0.so (brand spanking new lib with incompatible ABI) So now if you run the binary you made at the start it will use (tada) _the same old lib as before!_ ie. it will look to libm.so.6 (because that was hardcoded at compile time) and see it _still_ points to libm.2.3.5.so. _However_ if you were to compile it over again the linker would start off (again) by looking for libm.so, starting in /usr/lib, it would see that it now points to /lib/libm.so.7 and hardcode that into the new binary instead. Then when the new binary is run it will follow libm.so.7 and see that it now needs to use /lib/libm.3.0.so instead. I hope that helps a bit. Jack Brown -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: Linux-PAM nitpicks
Jack Brown wrote these words on 02/23/05 23:39 CST: > Steve Crosby wrote: >>hmm... > [snip headache inducing material :-)] > I hope that helps a bit. Geez. No offense, but that was pretty tough reading. How 'bout this instead: If you upgrade Glibc, start over from scratch. :-) -- Randy rmlinux: [GNU ld version 2.15.91.0.2 20040727] [gcc (GCC) 3.4.1] [GNU C Library 2004-07-01 release version 2.3.4] [Linux 2.6.8.1 i686] 23:43:00 up 18 days, 7:32, 7 users, load average: 0.17, 0.08, 0.02 -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: Linux-PAM nitpicks
Jack Brown wrote: Here's how I look at it: You go to compile something, it decides that it want's libm and starts off looking at /usr/lib to see what it can find. It comes across a file /usr/lib/libm.so which is linked to a file called /lib/libm.so.6. based on this it tells the linker to link the resulting binary to a file named /lib/libm.so.6. When you run the program it sees that it need to load up the file /lib/libm.so.6 and in doing so ends up following the symlink and ends up actually loading /lib/libm.2.3.4.so in the process. One small correction, Actually it tells the linker to hardcode libm.so.6 without the full path (whoops). Then it looks for libm.so.6 starting in /usr/lib, then in /lib. (and then I guess it starts searching through /etc/ld.so.cache for libs that are in directories specified in /etc/ld.so.conf, assuming ldconfig has been run since they were installed) Jack Brown -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: Linux-PAM nitpicks
Randy McMurchy wrote: Jack Brown wrote these words on 02/23/05 23:39 CST: Steve Crosby wrote: hmm... [snip headache inducing material :-)] I hope that helps a bit. Geez. No offense, but that was pretty tough reading. How 'bout this instead: If you upgrade Glibc, start over from scratch. :-) Sorry, Glibc is probably the least "real world" example because you probably would start over, but what I said applies to any lib, not just Glibc. Jack Brown -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
