Bugzilla Bug 195912

Hello,

I'm getting errors when compiling app-cdr/dvd+rw-tools-7.0 on an AMD64 system.
THe errors are preventing app-cdr/dvd+rw-tools-7.0 from being built. I've
attached tje output from the emerge.

Reproducible: Always

Steps to Reproduce:
1. emerge app-cdr/dvd+rw-tools

Actual Results:  
Compile error.

Expected Results:  
No errors.

Portage 2.1.3.13 (default-linux/amd64/2007.0, gcc-4.2.2, glibc-2.6.1-r0,
2.6.23-gentoo x86_64)
=================================================================
System uname: 2.6.23-gentoo x86_64 AMD Athlon(tm) 64 Processor 3200+
Timestamp of tree: Sun, 14 Oct 2007 21:00:03 +0000
app-shells/bash:     3.2_p17-r1
dev-java/java-config: 1.3.7, 2.1.2-r1
dev-lang/python:     2.4.3-r4, 2.5.1-r2
dev-python/pycrypto: 2.0.1-r6
sys-apps/baselayout: 1.12.10-r5
sys-apps/sandbox:    1.2.18.1
sys-devel/autoconf:  2.13, 2.61-r1
sys-devel/automake:  1.5, 1.7.9-r1, 1.8.5-r3, 1.9.6-r2, 1.10
sys-devel/binutils:  2.18-r1
sys-devel/gcc-config: 1.4.0-r4
sys-devel/libtool:   1.5.24
virtual/os-headers:  2.6.23
ACCEPT_KEYWORDS="amd64 ~amd64"
CBUILD="x86_64-pc-linux-gnu"
CFLAGS="-march=athlon64 -O2 -pipe"
CHOST="x86_64-pc-linux-gnu"
CONFIG_PROTECT="/etc /home/mythtv/"
CONFIG_PROTECT_MASK="/etc/env.d /etc/env.d/java/ /etc/fonts/fonts.conf
/etc/gconf /etc/php/apache2-php5/ext-active/ /etc/php/cgi-php5/ext-active/
/etc/php/cli-php5/ext-active/ /etc/revdep-rebuild /etc/terminfo
/etc/udev/rules.d"
CXXFLAGS="-march=athlon64 -O2 -pipe"
DISTDIR="/usr/portage/distfiles"
FEATURES="distlocks metadata-transfer sfperms strict unmerge-orphans userfetch"
GENTOO_MIRRORS="http://distfiles.gentoo.org
http://distro.ibiblio.org/pub/linux/distributions/gentoo"
MAKEOPTS="-j1"
PKGDIR="/usr/portage/packages"
PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --compress
--force --whole-file --delete --delete-after --stats --timeout=180
--exclude=/distfiles --exclude=/local --exclude=/packages
--filter=H_**/files/digest-*"
PORTAGE_TMPDIR="/var/tmp"
PORTDIR="/usr/portage"
SYNC="rsync://rsync.gentoo.org/gentoo-portage"
USE="acl amd64 berkdb bitmap-fonts cli cracklib crypt cups dri fortran gdbm gpm
iconv ipv6 isdnlog midi mmx mudflap ncurses nls nptl nptlonly openmp pam pcre
perl pppd python readline reflection session spl sse sse2 ssl tcpd
truetype-fonts type1-fonts unicode xorg zlib" ALSA_CARDS="ali5451 als4000
atiixp atiixp-modem bt87x ca0106 cmipci emu10k1x ens1370 ens1371 es1938 es1968
fm801 hda-intel intel8x0 intel8x0m maestro3 trident usb-audio via82xx
via82xx-modem ymfpci" ALSA_PCM_PLUGINS="adpcm alaw asym copy dmix dshare dsnoop
empty extplug file hooks iec958 ioplug ladspa lfloat linear meter mulaw multi
null plug rate route share shm softvol" ELIBC="glibc" INPUT_DEVICES="keyboard
mouse evdev" KERNEL="linux" LCD_DEVICES="bayrad cfontz cfontz633 glk hd44780
lb216 lcdm001 mtxorb ncurses text" LIRC_DEVICES="mceusb2" USERLAND="GNU"
VIDEO_CARDS="nvidia"
Unset:  CTARGET, EMERGE_DEFAULT_OPTS, INSTALL_MASK, LANG, LC_ALL, LDFLAGS,
LINGUAS, PORTAGE_COMPRESS, PORTAGE_COMPRESS_FLAGS, PORTAGE_RSYNC_EXTRA_OPTS,
PORTDIR_OVERLAY

Created an attachment (id=133493) [details]
Compile error.

Created an attachment (id=133495) [details]
Build log.

<snip>
growisofs.c: In function 'setup_fds':
growisofs.c:724: error: 'INT_MAX' undeclared (first use in this function)
growisofs.c:724: error: (Each undeclared identifier is reported only once
growisofs.c:724: error: for each function it appears in.)
In file included from growisofs_mmc.cpp:17:
transport.hxx: In member function 'int Scsi_Command::is_reload_needed(int)':
transport.hxx:358: error: 'INT_MAX' was not declared in this scopeIn file
included from dvd+rw-format.cpp:85:
transport.hxx: In member function 'int Scsi_Command::is_reload_needed(int)':
transport.hxx:358: error: 'INT_MAX' was not declared in this scope
In file included from dvd+rw-booktype.cpp:36:
transport.hxx: In member function 'int Scsi_Command::is_reload_needed(int)':
transport.hxx:358: error: 'INT_MAX' was not declared in this scope
</snip>

Same problem with dvd+rw-tools-6.1-r1.

Shrug, downgrade your linux-headers... WFM.

(In reply to comment #5)
> Shrug, downgrade your linux-headers... WFM.
> 
Yes, rebuilding after upgrading linux-headers to 2.6.23 I ran into the same
issue. I successfully rebuilt this package after upgrading other elements of
the toolchain (gcc 4.2.2, binutils 2.18.50.0.2) to the latest releases, the
only thing different this time is linux-headers.

Shouldn't this block bug #195298 which is the tracker for 2.6.23 linux-headers
regressions?

(In reply to comment #7)
> Shouldn't this block bug #195298 which is the tracker for 2.6.23 linux-headers
> regressions?

No,that bug is about 2.6.23 *kernel*, not about linux-headers. 

Any code that uses CDSL_NONE or CDSL_CURRENT from <linux/cdrom.h> will fail
unless INT_MAX is defined.  Including <limits.h> should fix it.

Created an attachment (id=133927) [details]
Adds #include <limits.h> to the files that need it 

I'm no programmer, but I decided to have a shot at created a patch to get this
working. Attached is what I came up with. I added it to an ebuild in overlay,
and it compiled. I haven't had a change to actually confirm the program works
once compiled. Hope this helps someone.

(In reply to comment #10)
> Created an attachment (id=133927) [edit] [details]
> Adds #include <limits.h> to the files that need it 
> 
> I'm no programmer, but I decided to have a shot at created a patch to get this
> working. Attached is what I came up with. I added it to an ebuild in overlay,
> and it compiled. I haven't had a change to actually confirm the program works
> once compiled. Hope this helps someone.

It looks like it works, but in fact you only need to add #include <limits.h> to
two files: growisofs.c and transport.hxx.

BTW, I reported the problem on the mailing list <cdwrite@other.debian.org> but
they weren't really interested and suggested filing a bug against
<linux/cdrom.h> (part of linux-headers).

Toolchain, do you consider this a dvd+rw bug or a linux-headers bug?

Isn't there a fix that can be committed to a patch here and put in portage?  It
seems the temporary fix has been found.  Or is it more complex than that?  Does
including limits.h where necessary to get this to compile under
linux-headers-2.6.23 break it under other linux-headers versions.
Please help, why should we maintain a broken system when a fix is evident?
Thanks.
James

Lets not be shy about fixing this, and Sedoroxs patch looks good enough for me.

Fixed! Thanks.

So should i sync now? Is this also commited in the ebuild? I donno exactly how
to apply the patches manually. Thanks

that is not the way to fix it ... i'll back that out

use linux-headers-2.6.23-r1