Makefile breaks with 2.6.8.1, plus cdcd data point.

[J. Kanowitz]

Hmm.  One of your users poked me for support this morning, with the
following problem while attempting to build a fresh kernel.  To quote
him:
 
---
make[3]: *** No rule to make target
`drivers/char/speakup/makemapdata',
 
needed by `drivers/char/speakup/mapdata.h'.  Stop.
make[2]: *** [drivers/char/speakup] Error 2
make[1]: *** [drivers/char] Error 2
make: *** [drivers] Error 2
kernel: 2.6.8.1
latest speakup, from checkout script.
---
 
I'm a BSD user, and I'm bad enough with BSD make, but I did check out
the repository and determine the Makefile was touched a few times in
fairly-'recent' history...  Unfortunately, this doesn't mean I'm
clued enough to guess what it could be.  (Would/could/should the fix of
"host-progs-y to hostprogs-y" be the culprit?  I'm not feeling like
walking someone through trial-and-error with an unfamiliar system.)
 
I'm also not sure what the ".1" in 2.6.8.1 could mean, but if this
sounds like a bad 2.6 to try with, recommendation of a 'blessed'
version might help.
 
Meanwhile, as relates to the thread on cdcd... He's a Debian user,
and I'm sure he's upgrading because of a bug we had with
2.4.24-1-speakup.  Linux has apparently only switched to a CAM-like
"ide-scsi" abstraction recently, and something about this, or changes
in the ata driver and associated APIs, saw the system failing to send
appropriate audio-playing commands to either of his CD drives, whether
addressing the 'ide-scsi' nodes (/dev/srN) or the ATA hdX devices
directly.  
 
To the user having trouble with "cdcd play" doing nothing, check your
dmesg after a playback attempt for errors like "sr1: CDROM not ready.
Make sure there is a disc in the drive," or "sr0: CDROM (ioctl) error."
If those are present, it's likely the same bug; if not, and the disc
can be heard spinning, perhaps you need to try the headphone jack on
the front of the drive?
 
At last check, there seemed to be some sort of confusion over which
API should now be used to send the ATAPI(?) commands, effectively
stranding the issue between the cdcd maintainers and the kernel
developers.  I had another user ask me about a similar issue with xmms
(which may rely on the same underlying library), so it sounds like
something systemic between software and certain revisions of 2.4. 
(Maybe compiling libcdaudio locally will produce a build that 'does the
right thing?'  I've yet to try this, or check to see if they have
anything in their build process that would account for it at
compile-time instead of runtime.)

-Oh well.  Thanks, for reading, hope someone can help!
-Joe "Floid" Kanowitz
cc:s appreciated, though I've subscribed to get this post through.  My
apologies if it shows up twice.