I couldn't get my webcam to work with my 2.6.15.4 kernel and I couldn't compile a new pwc module for it so I decided to go back to my last kernel (2.6.14.4) that worked with my webcam. However, because Pat just recently released new gcc and glibc packages I decided to roll a new 2.6.14.4 kernel to appease my Nvidia driver.

The new kernel works great and my webcam works too, but I noticed that ldconfig hangs for about 30-40 seconds at boot before moving on to the next stage. Previously it only took about 5 seconds. I checked my /etc/ldconfig.so.conf file and found two old entries (Firefox-1.06, now using Firefox-1.5.0.1 and OpenOffice-1.1.4, now using OpenOffice-2.0) so I deleted them. Then I ran ldconfig -v and found that there were two broken symlinks pointing to lib files which belonged to programs I uninstalled a long while ago so I deleted those broken symlinks. Now ldconfig -v has no complaints. I rebooted, but ldconfig still hangs for 30-40 seconds.

I decided to boot with the 2.6.15.4 kernel and ldconfig only took about 5 seconds again.

I want to go with the 2.6.14.4 kernel because everything works as it should with that kernel. I suppose I could just grin and bear the ldconfig problem, but something tells me I need to correct the problem or I'll have issues later.

Any suggestions?

LocoMojo

P.S. - Something funny happened. For as long as I've used Linux on this computer (almost 2 years) glxgears always reported 1500-1700 FPS and now suddenly with this new kernel I'm getting 6900-7100 FPS. Nice improvement, but WTF?

when you run ldconfig -v does it hang on anything?

No, not at all. It flies so fast I can't keep up with it to read it.

LocoMojo

try pipping it into file
than you can see it using

Why? That's no different than doing an ldconfig -v and then just scrolling back.

Like I said, I checked it out, ldconfig isn't complaining about anything and ldconfig isn't slow when I issue an ldconfig -v at the CLI.

The problem is, ldconfig is slow at boot, only at boot. I temporarily modified my /etc/rc.M file to issue an ldconfig -v instead of just ldconfig at boot and I can see ldconfig crawling at boot time.

Once I log in, if I issue an ldconfig again, it flies.

The problem is only at boot. I don't fully understand what's going on here and I don't fully understand ldconfig, but I'm thinking that at boot ldconfig is starting "anew" and then when I log in and do an ldconfig it's running from cache.

Then again that doesn't make sense because how would ldconfig find new libs after login if it is working from cache?

I can't figure it out. I don't know why ldconfig is crawling at boot time, but is super fast after login.

LocoMojo

Of course the simplest solution is to not run ldconfig at boot time. As long as you run it whenever you install new libraries, it really doesn't need to be run at every boot. In fact, turning off ldconfig at boot is usually one of the first things I do.

Really? You don't need ldconfig at boot? Ok, I didn't know that.

So the system remembers all the libraries after boot?

Why is it there in the first place? Just a convenience so you don't have to manually issue ldconfig whenever you install new stuff?

Thanks.

LocoMojo

I REALLY hate to speak for The Man, but I think that Pat put it in the startup scripts as a failsafe against people putting in new libraries but not running ldconfig. My understanding (always subject to being mistaken) is that ldconfig stores the needed library information in /etc/ld.so.cache, so as long as you don't add new libraries, that information doesn't really need to change. As I said, I always turn off the boot run of ldconfig and I have yet to see any downside.

Of course that does mean that any time you install libraries, you do need to run ldconfig on your own. My experience is that it is pretty easy simply because I'm usually trying to resolve a dependency for some program and that program simply isn't going to compile until I run ldconfig.

I would guess the slow ldconfig at boot time is a result of all the other stuff going on at boot. By the time you've gotten to a console, all the CPU and disk access load is probably significantly smaller and that is why ldconfig runs much faster.

"I would guess the slow ldconfig at boot time is a result of all the other stuff going on at boot. By the time you've gotten to a console, all the CPU and disk access load is probably significantly smaller and that is why ldconfig runs much faster."

That makes a whole lot of sense and that was what I was thinking.

I just wasn't sure if everything took turns during boot. In other words, I wasn't sure if each process didn't start until the previous process completed. That's what it looks like is happening during boot anyway.

I'm still confused though as to why ldconfig at boot completes in about 5 seconds with the 2.6.15.4 kernel and 30-40 seconds with the 2.6.14.4 kernel. In both cases everything is the same, the startup scripts are identical, the only difference is the kernel versions.

The only difference between the two kernels is the fact that ext3 and jbd are compiled into the 2.6.14.4 kernel and both kernels were compiled with different compilers (gcc-3.4.5 vs. gcc-3.4.6) and different glibc (2.3.5 vs. 2.3.6).

I know I sound like an anal prick, but one of the main reasons I switched from Windows to Linux was to wrest control from my computer. To me, simply turning this or that off because I'm having problems isn't really getting control, it is merely brushing things aside. To me, having control is understanding what's going on and knowing why this or that happens. In this situation, turning off ldconfig at boot is a "band-aid" solution and it is a solution without control. I very well may wind up turning it off, but I'd really like to know what's going on behind the scenes.

Also, as you can see from the thread starter, my glxgears is reporting a 400% increase in speed with this new kernel. A very pleasant bonus, but I don't know why it happened. I'm using the same drivers and I've changed nothing else relevant to the display, yet I'm getting this 400% increase in FPS speed. The only thing I could think of at this juncture is the fact that my Nvidia drivers were compiled with different compilers.

I don't mean to be a pain in the ass, but I'd really like to know what's going on and I really do appreciate your input as I've learned that ldconfig isn't necessary at boot.

LocoMojo

instead of waiting on ldconfig at boot time, i set it to run in the background.