Take the 2-minute tour ×
Unix & Linux Stack Exchange is a question and answer site for users of Linux, FreeBSD and other Un*x-like operating systems.. It's 100% free, no registration required.

I've built a newer (3.16-rc2) kernel which is running fine. My userspace program needs to link against the newer headers as it uses some new definitions in fcntrl.h etc.

My question is how do I preserve the headers of the old kernel when running "make headers_install" ?

If run

make headers_install INSTALL_HDR_PATH=/usr/src/kernels/`uname -r` 

Header definitions clash as /usr/src/include is still in the PATH.

Whats the proper way to handle this?

share|improve this question
    
Why do you want to preserve the old ones if you actually want to use the new ones? It's not going to make any difference to anything that's already compiled and installed, and if this is the kernel now used on the system, then in the future, the new headers are the ones that are best applicable. –  goldilocks Jul 31 at 18:30
    
Ideally, it would not make a difference. However, in the event that we need to use the older kernel, our userspace programs may not work on the older kernel. I just want to safeguard against this event. –  user3275885 Jul 31 at 19:01
    
If you need to use the header from the newer kernel, because, as you say, "my userspace program needs to link against the newer headers as it uses some new definitions", then what you are saying is my userspace program cannot work with an older kernel, so that's that. –  goldilocks Jul 31 at 19:05
    
Those features in the userspace program that use newer kernel mechanisms can be disabled. I just want to be able to preserve the old header structure. Perhaps I'm being paranoid but ... I rather imagine there is a way to handle this. I suppose I could save off the old headers and reinstall them. –  user3275885 Jul 31 at 19:17
    
Why don't you just make a backup copy of the old headers in a different place? –  celtschk Jul 31 at 19:18

1 Answer 1

up vote 1 down vote accepted

You can't #include two headers with an identical path, but you can install one outside of the normal paths and have it supersede those when you compile by using the appropriate switch (for gcc, -I). I think you understand that stuff already, so it should not take too much thinking to recognize that you if you place more than one asm/fcntl.h in normal include directories, only one of them will apply anyway.

I don't think you have much to worry about, however. Starting with some of your comments:

Those features in the userspace program that use newer kernel mechanisms can be disabled.

This is good. If you need #define NEWVALUE 666 in order to compile, and that involves a feature that will only work on a newer kernel and you can catch or disable the use of such otherwise, then the sections that actually apply NEWVALUE will never get called. Remember, it's not that there's no header defining this available when the old kernel is running -- even if there was, it wouldn't matter, since the real problem at runtime is that you've effectively invoked a non-existent part of the kernel ABI. You don't need any headers at all present just to run an executable, so going back to the old kernel won't matter for that.

Perhaps I'm being paranoid but...

Yes and no. If this is a system where various people arbitrary swap in different kernel headers in order to exploit new features when compiling stuff that's going to be left around and run later using an older kernel, then paranoia is an appropriate response, lol. However, there's probably not much that really falls into this category.

Distros replace the kernel headers at every upgrade, but the list of user land things they have to replace at the same time usually seems not so long (if it exists at all). I suppose that's in part because maintaining backward compatibility in this context is pretty easy, but I think it's also because things in this context don't change drastically over time.

I suppose I could save off the old headers and reinstall them.

You could do that, or you could replace them from the appropriate source when needed (make headers_install); if it's a distro kernel and you are worried they may be patched, the distro should have a source package for it.

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.