I'm trying to emerge sox as follows: >>> felicia ~ # emerge -pv sox These are the packages that I would merge, in order: Calculating dependencies ...done! [ebuild U ] media-sound/sox-12.17.7 [12.17.6-r1] +alsa -debug +encode +mad +oggvorbis 0 kB Total size of downloads: 0 kB <<< and then, without '-pv', it returns the following error: >>> felicia ~ # emerge sox Calculating dependencies ...done! >>> emerge (1 of 1) media-sound/sox-12.17.7 to / (.. left out ..) config.status: creating src/stconfig.h checking for stdint-types....... "(putting them into src/ststdint.h)" checking for uintptr_t... no checking for uintptr_t... no checking for uintptr_t... no checking for uintptr_t... no checking for uint32_t... no checking for uint32_t... no checking for uint32_t... no checking for uint32_t... no checking for u_int32_t... no checking for u_int32_t... no checking for u_int32_t... no checking for u_int32_t... no checking size of char... configure: error: cannot determine a size for char !!! Please attach the config.log to your bug report: !!! /var/tmp/portage/sox-12.17.7/work/sox-12.17.7/config.log !!! ERROR: media-sound/sox-12.17.7 failed. !!! Function econf, Line 485, Exitcode 0 !!! econf failed !!! If you need support, post the topmost build error, NOT this status message. <<< Reproducible: Always Steps to Reproduce: 1. emerge -pv sox 2. emerge sox 3. Actual Results: Please see attachment. Expected Results: Compile without any errors. felicia ~ # emerge info Portage 2.0.51-r15 (default-linux/amd64/2004.3, gcc-3.4.3, glibc-2.3.4.20050125-r0, 2.6.10-gentoo-r7 x86_64) ================================================================= System uname: 2.6.10-gentoo-r7 x86_64 AMD Opteron(tm) Processor 246 Gentoo Base System version 1.6.9 Python: dev-lang/python-2.3.5 [2.3.5 (#1, Feb 18 2005, 08:35:54)] ccache version 2.3 [enabled] dev-lang/python: 2.3.5 sys-devel/autoconf: 2.13, 2.59-r6 sys-devel/automake: 1.5, 1.7.9-r1, 1.6.3, 1.9.4, 1.4_p6, 1.8.5-r3 sys-devel/binutils: 2.15.92.0.2-r4 sys-devel/libtool: 1.5.10-r5 virtual/os-headers: 2.6.8.1-r3 ACCEPT_KEYWORDS="amd64 ~amd64" AUTOCLEAN="yes" CFLAGS="-march=k8 -fomit-frame-pointer -pipe -O3" CHOST="x86_64-pc-linux-gnu" CONFIG_PROTECT="/etc /usr/kde/2/share/config /usr/kde/3.3/env /usr/kde/3.3/share/config /usr/kde/3.3/shutdown /usr/kde/3/share/config /usr/lib/X11/xkb /usr/share/config /var/qmail/control" CONFIG_PROTECT_MASK="/etc/gconf /etc/terminfo /etc/env.d" CXXFLAGS="-march=k8 -fomit-frame-pointer -pipe -O3" DISTDIR="/usr/portage/distfiles" FEATURES="autoaddcvs autoconfig ccache distlocks sandbox sfperms strict userpriv usersandbox" GENTOO_MIRRORS="ftp://ftp-stud.fht-esslingen.de/pub/Mirrors/gentoo/ ftp://mirrors.sec.informatik.tu-darmstadt.de/gentoo/ http://ftp.du.se/pub/os/gentoo http://mirror.datapipe.net/gentoo http://adelie.polymtl.ca/" MAKEOPTS="-j3" PKGDIR="/usr/portage/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" SYNC="rsync://rsync.de.gentoo.org/gentoo-portage" USE="amd64 X acl acpi alsa apache2 apm arts audiofile avi berkdb bindist bitmap-fonts bonobo bzlib caps cdr crypt ctype cups curl dba dbx dga dio div4linux doc dvd dvdr encode esd evo exif f77 fam fastcgi flac font-server foomaticdb fortran ftp gd gdbm gif gmp gnutls gpm hardened hardenedphp iconv imap imlib ipv6 jp2 jpeg kde ldap libwww lzw lzw-tiff mad mbox memlimit mikmod motif mp3 mpeg multilib ncurses nls oav oggvorbis opengl oss pam pcntl pcre pdflib perl php png posix postgres python qt readline samba sasl sdl session shared slang slp sndfile sockets spl ssl sysvipc tcpd tiff tokenizer truetype truetype-fonts type1-fonts unicode usb userlocales xml2 xmms xpm xrandr xv xvid zlib linguas_de" Unset: ASFLAGS, CBUILD, CTARGET, LANG, LC_ALL, LDFLAGS, PORTDIR_OVERLAY
Created attachment 52150 [details] gcc config.log: /var/tmp/portage/sox-12.17.7/work/sox-12.17.7/config.log
Created attachment 52151 [details] emerge output
Same here; can't install k3b
that was a seperate issue with the amd64 toolchain, iirc it was related to USE="multilib" and gcc or glibc. is this still an issue?
I had the same problem on a x86 machine. After looking to config.log I realized that the portage user was not allowed to read and access the kernel's modules directory /lib/modules/version. After changing the rights of this directory from 750 to 755 the building of sox succeeded. :-) These wrong rights were probably intoduced when I changed the umask in /etc/profile to 'umask 027'. To prevent this sort of ebuild failures 'make modules_install' in the kernel builing process should not honor the umask but set the modules directory's right to 755.
(In reply to comment #5) > I had the same problem on a x86 machine. > > After looking to config.log I realized that the portage user was not allowed to > read and access the kernel's modules directory /lib/modules/version. After > changing the rights of this directory from 750 to 755 the building of sox > succeeded. :-) Thanks, this solved the problem for me, too. So I guess the ebuild is fine.
close the bug if this isn't a problem anymore
Reopen if it's still an issue.
*** Bug 117137 has been marked as a duplicate of this bug. ***
*** Bug 117712 has been marked as a duplicate of this bug. ***
(In reply to comment #5) > These wrong rights were probably intoduced when I changed the umask in > /etc/profile to 'umask 027'. To prevent this sort of ebuild failures 'make > modules_install' in the kernel builing process should not honor the umask but > set the modules directory's right to 755. Well, my umask in /etc/profile is the default 022, but the aforementioned directory is set as 700: =================== # ls -la /lib/modules/2.6.14-gentoo-r5 total 45 drwx------ 3 root root 488 Jan 4 18:50 . drwxr-xr-x 4 root root 112 Jan 3 21:50 .. lrwxrwxrwx 1 root root 31 Jan 3 21:50 build -> /usr/src/linux-2.6.14-gentoo-r5 drwx------ 6 root root 144 Jan 3 21:50 kernel -rw-r--r-- 1 root root 141 Jan 4 18:50 modules.alias -rw-r--r-- 1 root root 69 Jan 4 18:50 modules.ccwmap -rw-r--r-- 1 root root 1304 Jan 4 18:50 modules.dep =================== I can't remember deliberately changing it to 0700. Another box of mine (newer build), which compiled sox without trouble had indeed 0755 access rights. A few questions please, to help resolve my confusion: What determines the particular directory's default access rights - what should these be? How/why were these changed from the default, if indeed they were changed? How come that all other zillion emerges always complete without problems and sox is the one to now throw a wobbly? Since it has emerged successfully, do I return the access rights of that directory to the previous setting, or leave it as 0755? -- Regards, Mick
