[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: [Cdrecord-developers] Cdrtools-2.01a25: Patch to make cdrtools 2.01a25 Linux compatible



Ambrose Li wrote:
On Tue, Jan 27, 2004 at 10:06:46AM -0500, Greg Wooledge wrote:

  
True -- *but*, it must be pointed out that this is historic!
In a modern GNU/Linux distribution, /usr/include/linux should
*not* be a symlink to anything at all.  It should be a plain
directory containing the kernel header files with which the
GNU libc was built.
    
If this is true, I must respectfully point out that the real
problem is libc6. I upgraded my system to libc6 by hand, and
I *never* saw any advice (or "instruction" should be a better
word) to make /usr/include/linux a real directory, nor any
advice to keep the libc6-compile-time kernel header files
anywhere, nor any advice where to put the current kernel header
files.
  

Actually that info is in the Linux file standard, which has been available for some years. There are some distributions which don't follow that, all I can say is "there is a standard."
If such a drastic change in convention had taken place and
I have never read about it when I did my upgrade (which was
not very long ago -- I put off upgrading to libc6 until very
recently, and I did google for advice for fear of breaking my
system), then I have to agree with Joerg that Linux is being
very inconsistent, but I will say that the greatest problem is
not in the kernel, but in libc6.

  
Without getting into a flame war, he is saying that and then depending on installs to behave in some predictable manner which seems to be blaming Linux (which does have a standard) rather than doing defensive programming.

This also implies that cross compilation seems to need source edits, since having /usr/src/linux is optional and would point to the running kernel on the source system if present. It would make life easier for both Joerg and users to state that if the /usr/include/linux headers are not correct for the kernel on which the application will run, then the user must provide the information.

As an example:
  CDRTOOLS_KERNEL_INC=/root/my_2.6_includes
  make

Joerg is willing to put the responsibility for reading the multitude of README files on the user; many times he will point out that someone didn't follow README.multi or similar, and I think he is right. But he doesn't put the responsibility on the user to provide include pointers, and I think that's wrong. cdrtools should use /usr/include/linux unless told otherwise. Trying to guess which headers to use frustrates both the developer and the users, as the endless threads show.

Another approach would be to require the user to create a symlink to the includes in the cdrtools directory. And just don't compile until that's done. It not only gives the user a way to get it right, it forces the user to think, which is probably a good thing.

Odd distributions are a fact of life, and old distributions which have been updated are, too. I think we have proven that the build system can't correct for all the things people do, so why not make the user supply the information?
-- 
bill davidsen <davidsen@tmr.com>
  CTO TMR Associates, Inc
  Doing interesting things with small computers since 1979

Reply to: