scsi_interface.c:677:65: error: macro "memcpy" passed 12 arguments, but takes just 3 scsi_interface.c:698:63: error: macro "memcpy" passed 12 arguments, but takes just 3 scsi_interface.c:748:63: error: macro "memcpy" passed 12 arguments, but takes just 3 Reproducible: Always Steps to Reproduce: 1. emerge media-sound/cdparanoia 2. 3.
Created attachment 180376 [details] build.log
Created attachment 180378 [details] emerge --info
Created attachment 180379 [details, diff] patch to scsi_interface.c This additional patch fixes the install.
Created attachment 180381 [details, diff] gcc 4.3 patch file The previous patch file could be merged into the existing gcc fixes patch. This was just "cat /tmp/cdparanoia_scsi_gcc43.patch >> cdparanoia-3.10.2-gcc43.patch"
*** Bug 257049 has been marked as a duplicate of this bug. ***
/* read the header first */ unsigned char sense[SG_MAX_SENSE]; + const unsigned char orig_cmd[10] = { 0x43, 0, 0, 0, 0, 0, 1, 0, 12, 0}; unsigned char cmd[10] = { 0x43, 0, 0, 0, 0, 0, 1, 0, 12, 0}; cmd[1]=d->lun<<5; @@ -674,7 +675,7 @@ static int scsi_read_toc (cdrom_drive *d } for (i = first; i <= last; i++){ - memcpy(cmd, (char []){ 0x43, 0, 0, 0, 0, 0, 0, 0, 12, 0}, 10); + memcpy(cmd, orig_cmd, 10); IMHO the original code isn't wrong and its just gcc checks that are retarded...
you're using glibc-2.6 with gcc-4.3.3. that's a bad idea. can anyone reproduce this with glibc-2.8+ ?
cdparanoia merges correctly for me. Portage 2.2_rc23 (default/linux/x86/2008.0, gcc-4.3.3, glibc-2.9_p20081201-r1, 2.6.28-gentoo-r1 i686) ================================================================= System uname: Linux-2.6.28-gentoo-r1-i686-Intel-R-_Core-TM-2_Duo_CPU_E8200_@_2.66GHz-with-glibc2.0 Timestamp of tree: Fri, 30 Jan 2009 14:45:01 +0000 app-shells/bash: 3.2_p48 dev-lang/python: 2.5.4-r2 dev-python/pycrypto: 2.0.1-r6 sys-apps/baselayout: 2.0.0 sys-apps/openrc: 0.4.2 sys-apps/sandbox: 1.3.3 sys-devel/autoconf: 2.63 sys-devel/automake: 1.7.9-r1, 1.9.6-r2, 1.10.2 sys-devel/binutils: 2.19 sys-devel/gcc-config: 1.4.1 sys-devel/libtool: 2.2.6a virtual/os-headers: 2.6.28-r1 ACCEPT_KEYWORDS="x86 ~x86" CBUILD="i686-pc-linux-gnu" CFLAGS="-O2 -march=core2 -pipe" CHOST="i686-pc-linux-gnu" CONFIG_PROTECT="/etc /var/bind" CONFIG_PROTECT_MASK="/etc/ca-certificates.conf /etc/env.d /etc/fonts/fonts.conf /etc/gconf /etc/gentoo-release /etc/php/apache2-php5/ext-active/ /etc/php/cgi-php5/ext-active/ /etc/php/cli-php5/ext-active/ /etc/revdep-rebuild /etc/sandbox.d /etc/terminfo /etc/udev/rules.d" CXXFLAGS="-O2 -march=core2 -pipe" DISTDIR="/usr/portage/distfiles" FEATURES="distlocks fixpackages parallel-fetch preserve-libs protect-owned sandbox sfperms strict unmerge-orphans userfetch" GENTOO_MIRRORS="http://lug.mtu.edu/gentoo/" LDFLAGS="-Wl,-O1" MAKEOPTS="-j5" PKGDIR="/usr/portage/packages" PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --compress --force --whole-file --delete --stats --timeout=180 --exclude=/distfiles --exclude=/local --exclude=/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" SYNC="rsync://rsync.namerica.gentoo.org/gentoo-portage" USE="apache2 bzip2 cli crypt ctype curl ftp gd gnutls jpeg ldap mmx mysql mysqli pcre php png posix samba session socks5 sse sse2 sse3 ssl syslog truetype unicode urandom x86 zip zlib" APACHE2_MODULES="authz_host dir mime" ELIBC="glibc" INPUT_DEVICES="keyboard" KERNEL="linux" USERLAND="GNU" Unset: CPPFLAGS, CTARGET, EMERGE_DEFAULT_OPTS, FFLAGS, INSTALL_MASK, LANG, LC_ALL, LINGUAS, PORTAGE_COMPRESS, PORTAGE_COMPRESS_FLAGS, PORTAGE_RSYNC_EXTRA_OPTS, PORTDIR_OVERLAY
(In reply to comment #7) > you're using glibc-2.6 with gcc-4.3.3. that's a bad idea. can anyone > reproduce this with glibc-2.8+ ? > Should gcc 4.3.3 require glibc-2.8+ then? I'll try upgrading my glibc and see if i can reproduce it then.
Confirmed, cdparanoia does install cleanly with glibc 2.8: Portage 2.2_rc23 (default/linux/x86/2008.0, gcc-4.3.3, glibc-2.8_p20080602-r1, 2.6.28 i686) Is there any problem just applying the patch, so it "just works" regardless of your gcc/glibc version?
(In reply to comment #10) > Is there any problem just applying the patch, so it "just works" regardless of > your gcc/glibc version? The fix for this will not be found in the cdparanoia package. This is a toolchain issue. Gcc ought to depend uncoditionally on a recent-ish glibc. It's needed for amd64 anyway, IIRC.
Where "depend unconditionally" actually means in an elibc_glibc? ( ) condition, of course. Plus consideration for cross-compile.
glibc-2.8+ is forced now
(In reply to comment #7) > you're using glibc-2.6 with gcc-4.3.3. that's a bad idea. can anyone > reproduce this with glibc-2.8+ ? Can you explain why that's a bad idea?
because we don't test or support half-stable half-testing toolchains, and they are likely to break, like in this case. if you're going to use an ~arch keyworded complier, you will need to use a ~arch libc.
