Cannot emerge cdstatus-0.95.03, it fails during make. Also tried the ebuild available in bug 89497 with same problem. Reproducible: Always Steps to Reproduce: 1.emerge =cdstatus-0.95.03 2. 3. Actual Results: configure: creating ./config.status config.status: creating Makefile config.status: creating config.h config.status: executing depfiles commands make all-am make[1]: Entering directory `/var/tmp/portage/cdstatus-0.95.03/work/cdstatus-0.95.03' if i686-pc-linux-gnu-gcc -DHAVE_CONFIG_H -I. -I. -I. -O2 -funroll-loops -finline-functions -O2 -march=pent ium4 -fomit-frame-pointer -pipe -s -MT cdstatus.o -MD -MP -MF ".deps/cdstatus.Tpo" -c -o cdstatus.o cdstatus. c; \ then mv -f ".deps/cdstatus.Tpo" ".deps/cdstatus.Po"; else rm -f ".deps/cdstatus.Tpo"; exit 1; fi if i686-pc-linux-gnu-gcc -DHAVE_CONFIG_H -I. -I. -I. -O2 -funroll-loops -finline-functions -O2 -march=pent ium4 -fomit-frame-pointer -pipe -s -MT cdstatus_cddb.o -MD -MP -MF ".deps/cdstatus_cddb.Tpo" -c -o cdstatus_c ddb.o cdstatus_cddb.c; \ then mv -f ".deps/cdstatus_cddb.Tpo" ".deps/cdstatus_cddb.Po"; else rm -f ".deps/cdstatus_cddb.Tpo"; exit 1; fi In file included from cdstatus.c:15: /usr/include/sys/types.h:62: error: conflicting types for 'dev_t' /usr/include/linux/types.h:25: error: previous declaration of 'dev_t' was here /usr/include/sys/types.h:72: error: conflicting types for 'mode_t' /usr/include/linux/types.h:31: error: previous declaration of 'mode_t' was here /usr/include/sys/types.h:77: error: conflicting types for 'nlink_t' /usr/include/linux/types.h:34: error: previous declaration of 'nlink_t' was here In file included from /usr/include/sys/types.h:133, from cdstatus.c:15: /usr/include/time.h:104: error: conflicting types for 'timer_t' /usr/include/linux/types.h:43: error: previous declaration of 'timer_t' was here In file included from /usr/include/sys/types.h:216, from cdstatus.c:15: /usr/include/sys/select.h:78: error: conflicting types for 'fd_set' /usr/include/linux/types.h:22: error: previous declaration of 'fd_set' was here make[1]: *** [cdstatus.o] Error 1 make[1]: *** Waiting for unfinished jobs.... make[1]: Leaving directory `/var/tmp/portage/cdstatus-0.95.03/work/cdstatus-0.95.03' make: *** [all] Error 2 !!! ERROR: media-sound/cdstatus-0.95.03 failed. !!! Function src_compile, Line 556, Exitcode 2 !!! emake failed Expected Results: Proper successful emerge. ~ # emerge info Portage 2.0.51.19 (default-linux/x86/2005.0, gcc-3.4.3-20050110, glibc-2.3.4.20050125-r1, 2.6.11-darkphader-r6 i686) ================================================================= System uname: 2.6.11-darkphader-r6 i686 Intel(R) Pentium(R) 4 CPU 2.53GHz Gentoo Base System version 1.6.10 Python: dev-lang/python-2.3.5 [2.3.5 (#1, Feb 18 2005, 11:08:29)] distcc 2.18.3 i686-pc-linux-gnu (protocols 1 and 2) (default port 3632) [disabled] dev-lang/python: 2.3.5 sys-devel/autoconf: 2.59-r6, 2.13 sys-devel/automake: 1.7.9-r1, 1.8.5-r3, 1.5, 1.4_p6, 1.6.3, 1.9.5 sys-devel/binutils: 2.15.92.0.2-r8 sys-devel/libtool: 1.5.14 virtual/os-headers: 2.6.11 ACCEPT_KEYWORDS="x86 ~x86" AUTOCLEAN="yes" CFLAGS="-O2 -march=pentium4 -fomit-frame-pointer -pipe -s" CHOST="i686-pc-linux-gnu" CONFIG_PROTECT="/etc /usr/kde/2/share/config /usr/kde/3.4/env /usr/kde/3.4/share/config /usr/kde/3.4/shutdown /usr/kde/3/share/config /usr/lib/X11/xkb /usr/share/config /var/qmail/control" CONFIG_PROTECT_MASK="/etc/gconf /etc/terminfo /etc/texmf/web2c /etc/env.d" CXXFLAGS="-O2 -march=pentium4 -fomit-frame-pointer -pipe -s" DISTDIR="/usr/portage/distfiles" FEATURES="autoaddcvs autoconfig candy ccache distlocks sandbox sfperms strict" GENTOO_MIRRORS="ftp://gentoo.mirrors.pair.com http://mirrors.tds.net/gentoo http://open-systems.ufl.edu/mirrors/gentoo" MAKEOPTS="-j2" PKGDIR="/usr/portage/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="/usr/local/portage" SYNC="rsync://rsync.gentoo.org/gentoo-portage" USE="x86 X aac aalib acl acpi alsa apache2 arts audiofile avi bash-completion berkdb bitmap-fonts bonobo cdparanoia cdr crypt cups curl divx4linux dv dvb dvd dvdr emboss encode esd fam ffmpeg flac fortran gd gdbm gif gphoto2 gpm gstreamer gtk gtk2 gtkhtml guile imagemagick imap imlib ipv6 jack java jpeg jpeg2k kde lcd lcms ldap libg++ libwww mad mikmod mmx motif mp3 mpeg mysql ncurses nls nptl nvidia odbc ogg oggvorbis opengl oss pam pda pdflib perl png ppds python qt quicktime readline samba sasl scanner sdl slang slp speex spell sse ssl svg svga tcltk tcpd tetex theora threads tiff truetype truetype-fonts type1-fonts unicode usb v4l v4l2 vorbis win32codecs wmf xine xml xml2 xmms xv xvid zlib" Unset: ASFLAGS, CBUILD, CTARGET, LANG, LC_ALL, LDFLAGS, LINGUAS
Chris, If you would, manually unpack the tar.gz file from /usr/portage/distfile, edit cdstatus.c, and remove the line near the top that says: #include <sys/types.h> save and exit, then try: ./configure make If that works, I will probably remove that include from the source and release an updated revision. Compilers and standard libraries are unfortunately moving targets. When I first wrote that #include, it was required for compilation. On my current gentoo system (and several others I've tested on), the 0.95.03 in portage compiles cleanly as is. However, it also compiles for me without that #include now, and since that was the source of all the duplicate errors, it may be that removing it for you will fix the issue. This may also be a localized problem (with your libraries, headers, etc) because I have not been able to reproduce it on any system I have access to (which is 10 or so different gentoo systems, with different kernel versions and software installed).
Doesn't help but the error changes: make[1]: Entering directory `/usr/local/src/cdstatus-0.95.03' if gcc -DHAVE_CONFIG_H -I. -I. -I. -O2 -funroll-loops -finline-functions -g -O2 -MT cdstatus.o -MD -MP -MF ".deps/cdstatus.Tpo" -c -o cdstatus.o cdstatus.c; \ then mv -f ".deps/cdstatus.Tpo" ".deps/cdstatus.Po"; else rm -f ".deps/cdstatus.Tpo"; exit 1; fi In file included from /usr/include/stdlib.h:433, from cdstatus.c:18: /usr/include/sys/types.h:62: error: conflicting types for 'dev_t' /usr/include/linux/types.h:25: error: previous declaration of 'dev_t' was here /usr/include/sys/types.h:72: error: conflicting types for 'mode_t' /usr/include/linux/types.h:31: error: previous declaration of 'mode_t' was here /usr/include/sys/types.h:77: error: conflicting types for 'nlink_t' /usr/include/linux/types.h:34: error: previous declaration of 'nlink_t' was here In file included from /usr/include/sys/types.h:133, from /usr/include/stdlib.h:433, from cdstatus.c:18: /usr/include/time.h:104: error: conflicting types for 'timer_t' /usr/include/linux/types.h:43: error: previous declaration of 'timer_t' was here In file included from /usr/include/sys/types.h:216, from /usr/include/stdlib.h:433, from cdstatus.c:18: /usr/include/sys/select.h:78: error: conflicting types for 'fd_set' /usr/include/linux/types.h:22: error: previous declaration of 'fd_set' was here make[1]: *** [cdstatus.o] Error 1 As a note I'm running a fully ~x86 system plus it's set to use utf8 as the default.
Does it work with CFLAGS="-O2 -march=pentium4 -fomit-frame-pointer -pipe" (omit the -s)?
>Does it work with CFLAGS="-O2 -march=pentium4 -fomit-frame-pointer -pipe" (omit the -s)? No.
Just to add that 0.94a emerges just fine.
Also get the same failure on my laptop. It's ~x86 as well but not set to utf8 yet.
The conflict (after removing #include <sys/types.h> from explicit inclusion) seems to be between definitions in linux/types.h, and sys/types.h. Since (with sys/types.h not included) neither is included explicitly, it would seem that basic libraries like stdlib.h are including both and their definitions conflict. That seems to me like it is indicative of either inconsistent library versions, or flat broken library implementations. If you're willing to do so, I'd say try emerging your kernel-headers with x86 rather than ~x86 and try to rebuild cdstatus. Since your bug report, I've gone and compiled cdstatus on several more systems, including 2.4.x kernel and 2.6.x kernel systems with no issues whatsoever. While I definitely care about the issue you're encountering, unless I can get confirmation of the same issue with non-experimental configurations, I'm not going to spend too much time trying to chase it down. The nature of experimental configurations is that not everything works all the time; and since I have yet to see a non-experimental with any issues, I'm included to blame something related to non-stable software libraries, etc, rather than cdstatus itself. If you can get anyone on a non-experimental system to reproduce this, I'd be very glad to know, and treat it as a much higher priority.
>If you're willing to do so, I'd say try emerging your kernel-headers with x86 rather than ~x86 and try to rebuild cdstatus. Not willing at the present. My two ~x86 systems may, as you suspect, be broken. However, since the upgrade to the latest linux-headers and rebuilding the toolchains, I've emerged hundreds of packages on these two systems with no real problems. This includes the previous release of cdstatus as well, which still builds with no problems. Also, I have been led to believe that ~x86 is the testing branch and not "experimental" (which might be the -* masked ebuilds) and should normally be relatively stable. I do wish for clarification in case I am mistaken in this regard.
right, ~arch means testing and it can happen that things dont work all the time since it's nearly impossible to be aware of all possible configurations and mixes of the involved software while writing those software. sometimes things needs patching or things have to be fixed. that's what testing is for. package.mask is for things which are known to be broken.
Chris, please see if the following will compile for you (place it in something like test.c and try gcc <normal flags you use here> -o test test.c): #include <stdlib.h> int main(int argc, char **argv) { return 0; } If not, there's a major issue at work. stdlib.h includes both sys/types.h and linux/types.h and since they are what are generating conflicting definitions, I want to see if that woks. Lots and lots of software includes stdlib.h, so I can't imagine it's broken but I also don't see anything but conflicts between those two in the error messages you pasted. Also, my apologies for referring to ~x86 as 'experimental', testing is of course correct, I meant the word in the broader sense, not specific, as applied to the various software tree revisions. I am still working at trying to identify and/or correct the cause of this bug, but I have had zero luck in reproducing it so far. I notice that your compiler is at gcc 3.4.3, while mine is at 3.3.5, perhaps the newer version either a) is broken-ish, or b) is more picky about something like #include order than is 3.3.5. I will probably emerge the newer, testing version of gcc on one of my systems for comparison purposes.
test.c compiles just fine
If I order these lines in cdstatus.c as they are in version 0.94 then it works: #include <stdio.h> #include <sys/ioctl.h> #include <linux/cdrom.h> #include <stdlib.h> #include <sys/types.h> #include <sys/stat.h> #include <fcntl.h> #include <string.h> #include <strings.h> #include <errno.h> #include <unistd.h> #include <linux/types.h> The only difference between this group and the one in 0.94 is the addition of strings.h.
Created attachment 56843 [details, diff] patch to make cdtstatus-0.95.03 emerge succesfully under ~x86
Created attachment 56844 [details] updated ebuild to apply patch + a small correction corrected the einfo to inform that cdstaus.cfg needs to be copied as .cdstatus
Chris, thanks for your help in troubleshooting. At this point I was figuring it probably had to do with #include order, but I was going to have to take one of my stable (x86) systems to ~x86 in order to test compare, since I was trying to avoid asking you to play with the order ad infinitum. Just to clarify, is the uncommenting (effective readdition of) #include <linux/types.h> necessary for you to compile cleanly? It compiles cleanly without it at this point for me. If I can leave that #include out, I will, since there's no point including things I don't need to. If it is needed under ~x86 it probably is for someone on some other platform anyhow, and I'll leave it in. In either case, I'm probably going to re-release cdstatus with the modified #include order, and a slight change in the make install targets (to make sure I get the docs in place) at 0.95.04. (Note that if I were only releasing this to gentoo, I'd probably just call it 0.95.03-r1 or some such, but that revision syntax isn't as widely understood by package management systems, and using incrementing the rightmost of the 3 version numbers is the accepted GNU standard for sub-revisions of the same 'version'.
>Just to clarify, is the uncommenting (effective readdition of) #include <linux/types.h> necessary for you to compile cleanly? No, it doesn't need to be added back in (apparently it doesn't hurt either). I just started at that point and it all worked. Was wondering about that myself so I gave it a quick test at your request.
Created attachment 56859 [details, diff] updated cdstatus.patch doesn't add the line "#include <linux/types.h>" back in as it isn't necessary
cdstatus-0.95.04 is now up on sourceforge.net. It includes the re-ordered #include's and should fix/resolve this bug. The ebuild for cdstatus-0.95.03 should be removed and replaced with an almost identical one for cdstatus-0.95.04. Chris, If you would, download 0.95.04 off of sourceforge and verify proper operation in your environment.
new version is now in the tree, thanks for reporting and thanks to Nathanael for fixing the problem in a new release. feel free to reopen if the problem persists.
0.95.04 emerges fine sorry I didn't get to test it earlier the einfo in the 0.95.04 ebuild, unlike the modified 0.95.03 ebuild posted here, doesn't mention that "/usr/share/cdstatus.cfg" needs to copied as "~/.cdstatus"
