Re: linux-kernel-headers foul-up [RESOLVED]
On Sat, 08 Nov 2003 at 06:30:31 +0800, wrote: On Fri, 7 Nov 2003 at 11:17:10 +, Jonathan Dowland wrote: On Thu, Nov 06, 2003 at 09:19:45AM +0800, csj wrote: OPTFLAGS = ... -I/usr/local/src/linux/include /usr/local/src/linux should be the linux kernel source code. Apparently yes. I was doing things by trial and error and one of them the -I variants succeeded. Apparently no, at least as far as MPlayer is concerned. Otherwise the kernel headers aren't recognized. I also stumbled upon the ./configure option --with-extraincdir=DIR (which automates the trick). The specified extra include dir must also include the include. IRC I wasn't able to use this option some CVS versions earlier because the option didn't stuff its arguments in $OPTFLAGS but simply in $EXTRA_INC. $OPTFLAGS now references $EXTRA_INC (an ingeniously simple mod I must now admit): OPTFLAGS = -O4 -march=athlon -mcpu=athlon -pipe -ffast-math \ -fomit-frame-pointer -D_REENTRANT -D_LARGEFILE_SOURCE \ -D_FILE_OFFSET_BITS=64 $(EXTRA_INC) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: linux-kernel-headers foul-up [RESOLVED]
On Thu, Nov 06, 2003 at 09:19:45AM +0800, csj wrote: OPTFLAGS = ... -I/usr/local/src/linux/include /usr/local/src/linux should be the linux kernel source code. rhetorical Why else would the mplayer developers look for their headers by default in /usr/include/linux/? /rhetorical /usr/include/linux should be libc's linux kernel headers. Here is an exerpt from the #kernelnewbies FAQ at www.kernelnewbies.org: Kernel source headers These are the kernel header files that are part of the kernel source package. They should never be used for compiling user-space programs. Old Linux distributions often made /usr/include/linux and /usr/include/asm symlinks to the right parts of the kernel source tree installed in /usr/src/linux. This is the wrong thing to do - userspace programs must use copies of the kernel headers, suitably modified. There is also a link to Linus explaining the situation - http://www.ussg.iu.edu/hypermail/linux/kernel/0007.3/0587.html I can see a problem if developers wants to put out a source package of their latest and greatest program and it wants to link to the kernel. Where would they point it to? I imagine there are some very specific situations where a user space program would correctly need to include the linux kernel source path rather than libc's sanitized headers, but in virtually all cases they would opt for libc's ones - /usr/include/linux -- Jon Dowland http://jon.dowland.name/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: linux-kernel-headers foul-up [RESOLVED]
At Fri, 7 Nov 2003 11:17:10 +, Jonathan Dowland wrote: On Thu, Nov 06, 2003 at 09:19:45AM +0800, csj wrote: OPTFLAGS = ... -I/usr/local/src/linux/include /usr/local/src/linux should be the linux kernel source code. Apparently yes. I was doing things by trial and error and one of them the -I variants succeeded. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: linux-kernel-headers foul-up [RESOLVED]
On Wed, 5 Nov 2003 00:33:14 +,
Colin Watson wrote:
[...]
Applications that need kernel headers should make and use
sanitized private copies of the relevant interfaces in
kernel headers. They should never care about what happens
to be in /usr/include/{linux,asm}.
OK. A newbieish compile question: how do I point a program to
use, say, /usr/local/include/{linux,asm}?
Use gcc's -I flag.
Okay, thanks for the pointer. I can't find any options in
mplayer's ./configure script for this. I had to hack
./config.mak:
OPTFLAGS = -O4 -march=athlon -mcpu=athlon -pipe -ffast-math -fomit-frame-pointer
-D_REENTRANT -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -I/usr/local/src/linux/include
So maybe this story has a moral to it. Still, it seems to me
that Debian is doing some non-standard stuff. rhetorical Why
else would the mplayer developers look for their headers by
default in /usr/include/linux/? /rhetorical
I can see a problem if developers wants to put out a source
package of their latest and greatest program and it wants to link
to the kernel. Where would they point it to?
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: linux-kernel-headers foul-up
On Mon, Nov 03, 2003 at 10:12:07PM +0100, wsa wrote: Thanks for explaining this in the other thread aswell. What i wanted to ask, could this package be the cause of custom 2.4.22 kernels not going past INIT (today's update fixed this problem) which i and a few other people experienced over the last weekend? I doubt it. The original poster mentioned both mplayer and xawtv breakage, both i use because the server(mplayer self compiled)acts as a vcr aswell. Does this mean i should not recompile either one and leave them as is? If it's working, leave it alone. And last question, if this new splitting stuff causes breakage who will solve this? The split itself is a red herring. What breakage exists is due to source that tries to include kernel headers from /usr/include/linux and/or /usr/include/asm in userspace (always a risky proposition), and now gets confused because those headers are newer than the ones it expected. is this a debian issue, a linux issue or should the sources of for example mplayer be changed? Ultimately the source will have to be fixed as more and more distributions start using newer kernel headers. I believe the Debian glibc maintainers are patching around problems in this area for sarge. Cheers, -- Colin Watson [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: linux-kernel-headers foul-up
On Tue, Nov 04, 2003 at 06:30:47AM +0800, csj wrote: At Mon, 03 Nov 2003 22:12:07 +0100, wsa wrote: And last question, if this new splitting stuff causes breakage who will solve this? is this a debian issue, a linux issue or should the sources of for example mplayer be changed? Actually I can see the benefits of splitting. For me the problem was that the glibc team decided to use the broken (tm) 2.6 kernel. To support NPTL - which is going to be increasingly important for users over the duration of the next release cycle - there was no other alternative. The problem is that people included kernel headers from userspace, despite being told in lots of documentation not to do this. See debian-glibc over the last couple of months for lots of discussion about this. Fixing the problem should be as easy as rebuilding the linux-kernel-headers source by sticking in your own kernel-headers (from your custom make-kpkg kernel) into ./include and perhaps deleting the ./debian/patches directory. I really hope you know what you're doing in great detail. I would not remotely recommend this approach to anyone who isn't a seasoned glibc hacker. My proposed reportbug fix is to have linux-kernel-headers as a virtual provides package. Then we could have separate 2.2, 2.4 and 2.6 headers packages, the same way we already have separate kernel packages for 2.2, 2.4 and the broken 2.6 kernel. This won't work. The headers in /usr/include/linux and /usr/include/asm must match those against which glibc was compiled. You have to pick one; you can't swap them in and out freely. Again, the 2.6 headers are not broken. They're just different. Cheers, -- Colin Watson [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: linux-kernel-headers foul-up
On Tue, Nov 04, 2003 at 06:53:35AM +0800, csj wrote: On Mon, 3 Nov 2003 17:03:30 +, Colin Watson wrote: On Mon, Nov 03, 2003 at 09:52:16PM +0800, csj wrote: What precisely does this package do? It's listed as a dependency of the latest libc6 packages (which I made the mistake of compiling then installing). It includes the files in /usr/include/linux and /usr/include/asm which used to be part of libc6-dev. This is simply a packaging reorganization. Well, before the reorganization, I had an easy job recompiling mplayer and friends. See my other post. The reorganization itself is irrelevant. Programs written that way always had a sword of potential breakage hanging over them. The standard way to deal with this at the moment, suboptimal though it is, is to copy the header files you need from the kernel and include them in your own package; that way you're safe from changes to glibc. IMHO a better way would be to have linux-kernel-headers as a virtual package supplied by linux-kernel-headers-2.4, linux-kernel-headers-2.2 and linux-kernel-headers-2.6. Won't work. See /usr/share/doc/libc6/README.Debian.gz. I'm a bit suspicious of the version number: 2.5.999-test7-bk-6. The move to 2.6 headers was necessary in order to support NPTL in glibc. What's that? Native POSIX Threading Library: replaces LinuxThreads and does it right this time. Massive performance improvements and conformance to the POSIX threads specification. Cheers, -- Colin Watson [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: linux-kernel-headers foul-up
On Tue, Nov 04, 2003 at 06:30:47AM +0800, csj said At Mon, 03 Nov 2003 22:12:07 +0100, wsa wrote: Thanks for explaining this in the other thread aswell. What i wanted to ask, could this package be the cause of custom 2.4.22 kernels not going past INIT (today's update fixed this problem) which i and a few other people experienced over the last weekend? I have recompiled (and run) my custom 2.4.X kernel against the new libc6 without any problems. Just to clarify: your kernel makes NO USE AT ALL of your libc headers. The kernel is utterly unaware of libc and makes no use of it, ever. The original poster mentioned both mplayer and xawtv breakage, both i use because the server(mplayer self compiled)acts as a vcr aswell. Does this mean i should not recompile either one and leave them as is? Xine also fails to compile (ditto nvrec, a low overhead recording program). My conclusion: all video applications are affected. Eh? The only things that could possibly be affected are those using kernel headers because they need to access some to special kernel service, like the framebuffer. If you build mplayer/whatever without framebuffer support, it will not use the kernel headers at all. And last question, if this new splitting stuff causes breakage who will solve this? is this a debian issue, a linux issue or should the sources of for example mplayer be changed? Actually I can see the benefits of splitting. For me the problem was that the glibc team decided to use the broken (tm) 2.6 kernel. As Colin said, this was neccessary for NPTL support. They should be completely backwards compatible. Fixing the problem should be as easy as rebuilding the linux-kernel-headers source by sticking in your own kernel-headers (from your custom make-kpkg kernel) into ./include and perhaps deleting the ./debian/patches directory. Do you know what will happen if you start mixing things with NPTL support compiled in with these programs? I don't. My proposed reportbug fix is to have linux-kernel-headers as a virtual provides package. Then we could have separate 2.2, 2.4 and 2.6 headers packages, the same way we already have separate kernel packages for 2.2, 2.4 and the broken 2.6 kernel. These are for userspace, not kernel modules. The 2.5 kernel headers should work fine with any kernel at all. If there is a bug in them, it should be fixed, not replaced. Every time i start to think 'i'm getting the hang of linux' things like this happen...lib stuff...compile stuff...at times i think i need spiked mountain shoes to climb the learning curve ;) Welcome to Sid :-) -- Rob Weir [EMAIL PROTECTED] | [EMAIL PROTECTED] | Do I look like I want a CC? Words of the day: BLU-114/B Oil deals Europol South Africa e-bomb UOP basement signature.asc Description: Digital signature
Re: linux-kernel-headers foul-up
On Tue, 04 Nov 2003 00:10:49 +0100, wsa wrote: Well, I'm having serious problems with Mplayer, actually with mencoder to be exact. I have a load of automated 'vcr' recording scripts. These scripts have always worked and have given out the right kind of files with the right kind of bitrate(given in the script) correct timings, correct audio...and so...in short...perfectly fine mpeg 4 recordings. I also use some vcr scripts. But now I don't recall having run them with the new libc6 before I recompiled mplayer. The upgrade apparently took out some library my unpackaged mplayer (in /usr/local/stow) depended. I was forced to recompile. But xine and xawtv ran in their pristine Debian installed form. Right now running one of those scripts, so it's not me making a command mistake, result in an avi with the wrong bitrate, wrong timing/length (not running for the total given time), utterly messed up sound and so on.FUBAR. This is with an mplayer/mencoder version compiled from CVS which worked fine before this header stuff came along last friday, last time i did a compile of the mplayer source was about 2 weeks ago. So mencoder does run, but it has become useless. So apart from compile time this whole thing also messes up at least some already compiled programms. Maybe it's time to file a serious bug report against linux-kernel-headers. IMHO there should at least be two header packages, one for 2.4 and another for 2.6. One could be installed by default, but if that breaks your system you could install the alternate. If my suggestion is brain-damaged then perhaps someone could propose a better solution (hopefully not by forcing everybody to upgrade to 2.6). Speak up and be heard ;-). The future of your kernel-linked apps is in the air. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: linux-kernel-headers foul-up
On Tue, Nov 04, 2003 at 09:47:17AM +0800, csj wrote:
Maybe it's time to file a serious bug report against
linux-kernel-headers. IMHO there should at least be two header
packages, one for 2.4 and another for 2.6. One could be
installed by default, but if that breaks your system you could
install the alternate.
No, this is WRONG, and it WILL NOT WORK. You can't swap in another set
of stuff under /usr/include/{linux,asm} that disagrees with what glibc
was compiled with. That hierarchy is chiefly for glibc's internal use;
applications were never supposed to use it directly.
Applications that need kernel headers should make and use sanitized
private copies of the relevant interfaces in kernel headers. They should
never care about what happens to be in /usr/include/{linux,asm}.
Cheers,
--
Colin Watson [EMAIL PROTECTED]
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: linux-kernel-headers foul-up
On Mon, Nov 03, 2003 at 10:12:07PM +0100, wsa wrote: Every time i start to think 'i'm getting the hang of linux' things like this happen...lib stuff...compile stuff...at times i think i need spiked mountain shoes to climb the learning curve ;) if you run unstable, you can get exactly what you asked for :-) Although in general it is fine. -- Jon Dowland http://jon.dowland.name/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: linux-kernel-headers foul-up
On Tue, Nov 04, 2003 at 04:37:04PM +, Colin Watson wrote:
That hierarchy [/usr/include/{linux,asm}] is chiefly for glibc's
internal use; applications were never supposed to use it directly.
If these are supposed to be private, why are they now
provided in a seperate package?
--
Jon Dowland
http://jon.dowland.name/
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: linux-kernel-headers foul-up
On Tue, 4 Nov 2003 20:36:21 +1100, Rob Weir wrote: [...] Xine also fails to compile (ditto nvrec, a low overhead recording program). My conclusion: all video applications are affected. Eh? The only things that could possibly be affected are those using kernel headers because they need to access some to special kernel service, like the framebuffer. If you build mplayer/whatever without framebuffer support, it will not use the kernel headers at all. Well, to get your tv card to wrok you need kernel level support. So I can't compile mplayer with the new headers installed and enable its TV viewing and recording features at the same time. And last question, if this new splitting stuff causes breakage who will solve this? is this a debian issue, a linux issue or should the sources of for example mplayer be changed? Actually I can see the benefits of splitting. For me the problem was that the glibc team decided to use the broken (tm) 2.6 kernel. As Colin said, this was neccessary for NPTL support. They should be completely backwards compatible. I can't argue with that. All my other programs are running without crashing. I'm talking about hassle-free compiling, which is the most important part of the Debian experience. Fixing the problem should be as easy as rebuilding the linux-kernel-headers source by sticking in your own kernel-headers (from your custom make-kpkg kernel) into ./include and perhaps deleting the ./debian/patches directory. Do you know what will happen if you start mixing things with NPTL support compiled in with these programs? I don't. Well they're userspace programs (all installed in /usr/local/stow). So the worse I expect is a user program crash. I don't run mplayer as root. Then again the parent post in question was dealing with hacks. So fix was used in a relative sense, kind of like fixing your fuzzy TV by kicking it. (Try it sometimes, it does work. Just do kick it too hard.) My proposed reportbug fix is to have linux-kernel-headers as a virtual provides package. Then we could have separate 2.2, 2.4 and 2.6 headers packages, the same way we already have separate kernel packages for 2.2, 2.4 and the broken 2.6 kernel. These are for userspace, not kernel modules. But they really don't work with some programs that must compile against certain kernel features. And some programs do need to use kernel level features or they won't work at all. How do you for example disable the framebuffer feature for a framebuffer video player (fbxine or fbtv). So if I want to compile a full-featured mplayer I have to resort to some ugly, non-Debian hack (cobbling together a private package containing the 2.4 headers so that I could easiy uninstall later). If there's a kernel-headers package for 2.4 then I could install that to get an elegant, Debian-sanctioned hack. The 2.5 kernel headers should work fine with any kernel at all. If there is a bug in them, it should be fixed, not replaced. Well, I wasn't ranting about the kernel headers being kernel-incompatible, which was kind of the point of my saying that I managed to recompile my kernel because it doesn't depend on whatever is in linux-kernel-headers (because it has its own headers to worry about). -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: linux-kernel-headers foul-up
On Tue, 4 Nov 2003 16:37:04 +,
Colin Watson wrote:
On Tue, Nov 04, 2003 at 09:47:17AM +0800, csj wrote:
Maybe it's time to file a serious bug report against
linux-kernel-headers. IMHO there should at least be two header
packages, one for 2.4 and another for 2.6. One could be
installed by default, but if that breaks your system you could
install the alternate.
No, this is WRONG, and it WILL NOT WORK. You can't swap in
another set of stuff under /usr/include/{linux,asm} that
disagrees with what glibc was compiled with. That hierarchy is
chiefly for glibc's internal use; applications were never
supposed to use it directly.
I get your point. But can't we treat 2.6 the way we treat The
Hurd ;-)?
Applications that need kernel headers should make and use
sanitized private copies of the relevant interfaces in kernel
headers. They should never care about what happens to be in
/usr/include/{linux,asm}.
OK. A newbieish compile question: how do I point a program to
use, say, /usr/local/include/{linux,asm}?
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: linux-kernel-headers foul-up
On Tue, Nov 04, 2003 at 09:00:32PM +, Jonathan Dowland wrote:
On Tue, Nov 04, 2003 at 04:37:04PM +, Colin Watson wrote:
That hierarchy [/usr/include/{linux,asm}] is chiefly for glibc's
internal use; applications were never supposed to use it directly.
If these are supposed to be private, why are they now
provided in a seperate package?
Because they're easier for the glibc maintainers to manage that way.
--
Colin Watson [EMAIL PROTECTED]
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: linux-kernel-headers foul-up
On Wed, Nov 05, 2003 at 05:48:59AM +0800, csj wrote:
On Tue, 4 Nov 2003 16:37:04 +,
Colin Watson wrote:
On Tue, Nov 04, 2003 at 09:47:17AM +0800, csj wrote:
Maybe it's time to file a serious bug report against
linux-kernel-headers. IMHO there should at least be two header
packages, one for 2.4 and another for 2.6. One could be
installed by default, but if that breaks your system you could
install the alternate.
No, this is WRONG, and it WILL NOT WORK. You can't swap in
another set of stuff under /usr/include/{linux,asm} that
disagrees with what glibc was compiled with. That hierarchy is
chiefly for glibc's internal use; applications were never
supposed to use it directly.
I get your point. But can't we treat 2.6 the way we treat The
Hurd ;-)?
Smiley noted, but not really an option; given the length of release
cycles for the moment, we have to be foresighted.
Applications that need kernel headers should make and use
sanitized private copies of the relevant interfaces in kernel
headers. They should never care about what happens to be in
/usr/include/{linux,asm}.
OK. A newbieish compile question: how do I point a program to
use, say, /usr/local/include/{linux,asm}?
Use gcc's -I flag.
Cheers,
--
Colin Watson [EMAIL PROTECTED]
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: linux-kernel-headers foul-up
Ok, maybe I'm REALLY missing the signal in all the noise, but whyinhell are people having a problem with this? If an application needs kernel headers, whyinhell isn't it USING them? That, after all, is why you put a kernel source tree in place on your system. Any number of packages depend on having one or another kernel-headers package installed. I build lm-sensors, it uses the kernel headers. I build nVidia drivers, it uses the kernel headers. NOT whatever headers glibc might have installed on the box. Any application that expects to be able to use glibc headers and gain access to kernel structures is fundamentally broken, isn't it? The glibc headers are for gaining access to *glibc* structures. They have to match *glibc*. Isn't all this noise a holdover from the mistaken idea that you were supposed to have your includes directory symlinked into your kernel source tree? -- Marc Wilson | *** System shutdown message from root *** [EMAIL PROTECTED] | System going down in 60 seconds -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: linux-kernel-headers foul-up
On Mon, Nov 03, 2003 at 09:52:16PM +0800, csj wrote: What precisely does this package do? It's listed as a dependency of the latest libc6 packages (which I made the mistake of compiling then installing). It includes the files in /usr/include/linux and /usr/include/asm which used to be part of libc6-dev. This is simply a packaging reorganization. The package appears to introduce massive breakage when compiling any program that links to some kernel function (e.g. mplayer and xawtv doing framebuffer video). Programs written that way always had a sword of potential breakage hanging over them. The standard way to deal with this at the moment, suboptimal though it is, is to copy the header files you need from the kernel and include them in your own package; that way you're safe from changes to glibc. I'm a bit suspicious of the version number: 2.5.999-test7-bk-6. The move to 2.6 headers was necessary in order to support NPTL in glibc. Cheers, -- Colin Watson [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: linux-kernel-headers foul-up
Thanks for explaining this in the other thread aswell. What i wanted to ask, could this package be the cause of custom 2.4.22 kernels not going past INIT (today's update fixed this problem) which i and a few other people experienced over the last weekend? The original poster mentioned both mplayer and xawtv breakage, both i use because the server(mplayer self compiled)acts as a vcr aswell. Does this mean i should not recompile either one and leave them as is? And last question, if this new splitting stuff causes breakage who will solve this? is this a debian issue, a linux issue or should the sources of for example mplayer be changed? Every time i start to think 'i'm getting the hang of linux' things like this happen...lib stuff...compile stuff...at times i think i need spiked mountain shoes to climb the learning curve ;) cheers Colin Watson wrote: It includes the files in /usr/include/linux and /usr/include/asm which used to be part of libc6-dev. This is simply a packaging reorganization. Programs written that way always had a sword of potential breakage hanging over them. The standard way to deal with this at the moment, suboptimal though it is, is to copy the header files you need from the kernel and include them in your own package; that way you're safe from changes to glibc. The move to 2.6 headers was necessary in order to support NPTL in glibc. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: linux-kernel-headers foul-up
At Mon, 03 Nov 2003 22:12:07 +0100, wsa wrote: Thanks for explaining this in the other thread aswell. What i wanted to ask, could this package be the cause of custom 2.4.22 kernels not going past INIT (today's update fixed this problem) which i and a few other people experienced over the last weekend? I have recompiled (and run) my custom 2.4.X kernel against the new libc6 without any problems. The original poster mentioned both mplayer and xawtv breakage, both i use because the server(mplayer self compiled)acts as a vcr aswell. Does this mean i should not recompile either one and leave them as is? Xine also fails to compile (ditto nvrec, a low overhead recording program). My conclusion: all video applications are affected. This is as far as compiling goes. I've seen no problems with a previously working program suddenly failing to run. And last question, if this new splitting stuff causes breakage who will solve this? is this a debian issue, a linux issue or should the sources of for example mplayer be changed? Actually I can see the benefits of splitting. For me the problem was that the glibc team decided to use the broken (tm) 2.6 kernel. Fixing the problem should be as easy as rebuilding the linux-kernel-headers source by sticking in your own kernel-headers (from your custom make-kpkg kernel) into ./include and perhaps deleting the ./debian/patches directory. Install the hacked package over the official Debian version, and you're good to recompile mplayer, xine, xawtv and friends. To be on the safe side, restore the official Debin package after the operation. My proposed reportbug fix is to have linux-kernel-headers as a virtual provides package. Then we could have separate 2.2, 2.4 and 2.6 headers packages, the same way we already have separate kernel packages for 2.2, 2.4 and the broken 2.6 kernel. Every time i start to think 'i'm getting the hang of linux' things like this happen...lib stuff...compile stuff...at times i think i need spiked mountain shoes to climb the learning curve ;) Things like these don't happen to normal people. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: linux-kernel-headers foul-up
On Mon, 3 Nov 2003 17:03:30 +, Colin Watson wrote: On Mon, Nov 03, 2003 at 09:52:16PM +0800, csj wrote: What precisely does this package do? It's listed as a dependency of the latest libc6 packages (which I made the mistake of compiling then installing). It includes the files in /usr/include/linux and /usr/include/asm which used to be part of libc6-dev. This is simply a packaging reorganization. Well, before the reorganization, I had an easy job recompiling mplayer and friends. The package appears to introduce massive breakage when compiling any program that links to some kernel function (e.g. mplayer and xawtv doing framebuffer video). Programs written that way always had a sword of potential breakage hanging over them. The standard way to deal with this at the moment, suboptimal though it is, is to copy the header files you need from the kernel and include them in your own package; that way you're safe from changes to glibc. IMHO a better way would be to have linux-kernel-headers as a virtual package supplied by linux-kernel-headers-2.4, linux-kernel-headers-2.2 and linux-kernel-headers-2.6. I'm a bit suspicious of the version number: 2.5.999-test7-bk-6. The move to 2.6 headers was necessary in order to support NPTL in glibc. What's that? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: linux-kernel-headers foul-up
Well, I'm having serious problems with Mplayer, actually with mencoder to be exact. I have a load of automated 'vcr' recording scripts. These scripts have always worked and have given out the right kind of files with the right kind of bitrate(given in the script) correct timings, correct audio...and so...in short...perfectly fine mpeg 4 recordings. Right now running one of those scripts, so it's not me making a command mistake, result in an avi with the wrong bitrate, wrong timing/length(not running for the total given time), utterly messed up sound and so on.FUBAR. This is with an mplayer/mencoder version compiled from CVS which worked fine before this header stuff came along last friday, last time i did a compile of the mplayer source was about 2 weeks ago. So mencoder does run, but it has become useless. So apart from compile time this whole thing also messes up at least some already compiled programms. Cheerios csj wrote: Xine also fails to compile (ditto nvrec, a low overhead recording program). My conclusion: all video applications are affected. This is as far as compiling goes. I've seen no problems with a previously working program suddenly failing to run. The original poster mentioned both mplayer and xawtv breakage, both i use because the server(mplayer self compiled)acts as a vcr aswell. Does this mean i should not recompile either one and leave them as is? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
