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
Randy McMurchy wrote:
Bruce Dubbs wrote these words on 02/22/05 11:23 CST:
I read the thread that Jack gave and Gerard wants to keep the links in
both places: /usr/lib because they are needed and /lib for consistency.
After all, this is primarily an LFS issue and only marginally a BLFS
Pardon my jumping in here but all of this discussion about PAM
reminded me of an issue from a while back regarding segmentation
faults with PAM/Shadow/Cracklib (as seen in the threads linked to
below). Someone on IRC was having the same sort of issues just
yesterday. Has this matter been solved?
Gerard Beekmans [EMAIL PROTECTED] wrote in
news:[EMAIL PROTECTED]:
On February 22, 2005 01:18 pm, Randy McMurchy wrote:
See the difference?
There are no .so files in /lib for Readline and Shadow. There is for
PAM. This is what I've been trying to say all along.
Additionally, the PAM .so
Steve Crosby wrote these words on 02/22/05 19:56 CST:
How does that gel with the paragraphs above? libm-2.3.4.so is the actual
runtime library, not only the compile\linking library...
Though I'm not certain Gerard was just talking about symlinks named
*.so, I was. The whole point of this
