Using kernel 2.6.32, what advices or recommendations when compiling software from source or 3rd. It's a dumb question but I ask me if in a production server ?!.I'm aware about glibc and kernel-headers (http://www.linuxquestions.org/questi...headers-194957 Thanks again, gnashley )

Norton Luiz.

I thought about running .32 too, but decided it'd be too risky running a kernel older than that used to build libc + headers (the kernel interface may have changed in a incompatible way).

I briefly thought about rebuilding libc against .32, but that's starting to get a little too involved and I'm not sure whether I'd then have to rebuild everything else too (I suspect I would).

1 members found this post helpful.

I thought you would only have issues when using new features from new kernels. Slackware's GLIBC is built with compatibility back to 2.6.18.

If you read the docs included with glibc, it says this.
I haven't noticed any issues so far.

One thing that usually causes problems, is when you compile software on one system with a newer glibc, and attempt to use that binary package on another system with an older glibc.

2 members found this post helpful.

Just as a test I built 2.6.32.15 on 13.1 and didn't notice any problems, but I didn't do much with it.

Thanks damgar. I wasn't aware of that compatibility option. That would seem to suggest that everything should be fine with running 2.6.32 on Slackware 13.1.

Strangely, this quote is a little bit odd:
Isn't that the most common way that it tends to happen? People run their distro's default libc but with newer kernels as they come out? Perhaps they're only talking about the situation when the headers used to compile the libc are older than the kernel you're running on but that kernel is still older than libc is. If the kernel is younger than libc then there's not going to be any support for any new features that are in there anyway. God this is confusing! I start to see why the OpenBSD guys insist on keeping kernel/system/headers and libc all in step with each other for each release now.

Anyway, thanks for the info. I've learnt something new here.

Thanks,

disturbed1, GazL and damgar.

I think they're referring to upgrading the kernel headers.

For years, my main OS had the headers from linux-2.4.31 installed. I had upgraded the kernel several times over the years, even into the 2.6 series. In the end, it still had the 2.4.31 headers and ran for 12 months on linux-2.6.16.22 before I started afresh with a clean install.

To answer the OP's question, your system will be perfectly stable as long as you don't touch glibc or the kernel headers. You can use any kernel you want, back to version 2.6.18.

2 members found this post helpful.

I'm not sure that's it. Re-reading that section, I think they mean exactly what they say:
Their example citing "availability of new features" seems to support this.


However, nothing gets removed from the kernel without spending a significant amount of time in a 'deprecated' state, and while new kernel features will not be available to a library compiled against older headers, they'll not be getting used either. So, while it "does not necessarily work", it actually does tend to work in practice, and that is pretty much the status quo for most of our systems.

I think they're just being cautious and warning that there's no guarantee it won't break on a newer kernel.


Anyway, in summary it seems that:

• The kernel headers used to compile libc should remain frozen at the version used to build it.
  
• Compatibility with older kernels is provided by compatibility code included in the library at build time with the --enable-kernel= option.
  
• Newer kernels may not necessarily work with an older libc, but in practice they do tend to, and we do it all the time.

Does that sound about right?

damgar, just curious. what kernel .config file did you start with?

This post to the LKML might help explain it a bit. Despite it's age, the information it contains is still relevant and correct.
http://lkml.indiana.edu/hypermail/li...07.3/0587.html

To clear things up a bit, Linus is referring to the headers under /usr/include/. These are the ones used to compile glibc.

To muddy the waters, Debian breaks the kernel source tree out into several packages. To what end, I don't know... but the one containing the in-tree kernel headers is called, "kernel-headers." They call the /usr/include headers, "libc headers." I've had a couple of arguments here with Debian users, due to this confusion.

Slackware doesn't break up the kernel source tree, so the "kernel-headers" package on a Slackware box is the one used to compile glibc. This should never be upgraded unless there is a new glibc package to go with it.

Cheers,

Rob

1 members found this post helpful.

Hmm, those zany debian guys!

Actually, I think they have a point labelling the package containing /usr/include headers as libc headers. I don't really see the value of breaking out the in-tree headers into a separate package though. Maybe it'll allow you to build 3rd party kernel modules without having to install the full kernel source, but I don't really see why you'd be worried about that.

Thanks for the link to Linus' post Rob. I had read that before, and I'm pretty happy I understand what's going on now.

I keep a kind of "stock-custom" kernel config. Basically it's a slackware-generic, with ext3/4 built in, PAE, timers, CPU, etc customized. It tends to get updated with the defaults from "make oldconfig" for each new kernel I build (whenever versions, RC's or boredom cause me to check out the new kernels) unless I see something that pertains to my setup particularly. I actually used the 2.6.33.3 config file because it was the oldest version I had on the machine I was working with at the time.