Re: [Cdrecord-video] Re: Cdrtools-2.01a25 ready
>From: Meino Christian Cramer <Meino.Cramer@gmx.de>
>The problem is, that the compilation process done by the makefile
>system of cdrecord does not break hard on compilation errors.
>The compilation error was in line 69 of ./libscg/scsi-linux-sg.c.
>It does a #include <scsi/scsi.h>, which let the source include
>/usr/src/linux/include/scsi/scsi.h.
>If line 69 of the offending code will be changed to
>#include "/usr/include/scsi/scsi.h" the non-kernel header file
>will be included and everything works well.
Note that libscg needs to include recent kernel include files
in order to be able to support recent kernel SCSI transport
interfaces.
The problem you observe is caused by broken Linux kernel include files.
Send a bug report to the Linux Kernel folks.
Unfortumately, the Linux kernel people don't understand this and
refuse to fix the inconsistensistencies in their code.
Let me explain it to you. There are three types of interfaces, you can see in
libc and /usr/include/*:
1) Interfaces that are fully created by libc, such as strcpy()
2) Interfaces that are defined by the kernel but propagated by libc.
Interfaces of this type are things similar to open()/read()/write(),..
3) Interfaces that libc is not even aware of (like ioctl() functions).
If major()/minor()/makedev() are CPP macros and not functions in libc,
then they are part of this group of interfaces.
Interfaces of type 1) are independent from the kernel and for this reason,
the statements from Linus on how (from his belief) include files should be
treatened apply _only_ to these interfaces.
To allow an application to match the interface, you need an include file that
is published by the same instance or person who does work on libc.
Interfaces of type 2) require that libc and the kernel version match. This
means, that you need to recompile and in some cases even to modify the libc
sources in order to get a working complete system every time the kernel
interface (used by libc) changes. This is needed to keep the upper level
interface from libc stable.
Interfaces of type 3) are independent of libc!
Any application that likes to use them, _needs_ to use the include files from
the kernel they are going to be run on. This is the only way, to make sure
that the user level application uses an interface that matches the adjacent
interface from the kernel. If you use different include files, you are unable
to even test the kernel interface. For this reason, it is important that all
include files from the kernel (that define interfaces that are visible from
user land) are written in a way that allows a consistent usage from a user
land application (which does never #define __KERNEL or similar).
Cdrecord is definitely a user land application that needs to be compiled with
the include files from the current kernel - otherwise it could not e.g. use
new features from SCSI drivers inside the kernel.
Star with respect to device major/minor handling is another one.
Jörg
--
EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin
js@cs.tu-berlin.de (uni) If you don't have iso-8859-1
schilling@fokus.fraunhofer.de (work) chars I am J"org Schilling
URL: http://www.fokus.fraunhofer.de/usr/schilling ftp://ftp.berlios.de/pub/schily
Reply to: