All seems to go wrong from here during compilation: rm -f prog/sensors/*.rd prog/sensors/*.ro rm -f prog/sensors/sensors rm -f lm_sensors-* /bin/sh: -/: invalid option Usage: /bin/sh [GNU long option] [option] ... /bin/sh [GNU long option] [option] script-file ... GNU long options: --debug --debugger --dump-po-strings --dump-strings --help --init-file --login --noediting --noprofile --norc --posix --protected --rcfile --restricted --verbose --version --wordexp Shell options: -irsD or -c command or -O shopt_option (invocation only) -abefhkmnptuvxBCHP or -o option /bin/sh: -print-search-dirs: command not found Next, it compiles a couple of files and then many of these occur: sed -e 's@^\(.*\)\.o:@prog/sensors/chips.rd prog/sensors/chips.ro: Makefile '`dirname prog/sensors/chips.rd`/Module.mk' @' > prog/sensors/chips.rd M -MG -I. -Ikernel/include -I/var/tmp/portage/lm-sensors-2.8.7/work/i2c-headers -Wall -O2 -O3 -ffast-math -mfpmath=sse -ftracer -fomit-frame-pointer -pipe -fno-stack-protector prog/sensors/main.c | \ sed -e 's@^\(.*\)\.o:@prog/sensors/main.rd prog/sensors/main.ro: Makefile '`dirname prog/sensors/main.rd`/Module.mk' @' > prog/sensors/main.rd /bin/sh: M: command not found /bin/sh: M: command not found And later before the ebuild stops, it does: I. -Ikernel/include -I/var/tmp/portage/lm-sensors-2.8.7/work/i2c-headers -fpic -Wall -O2 -O3 -ffast-math -mfpmath=sse -ftracer -fomit-frame-pointer -pipe -fno-stack-protector -Wno-unused -c lib/conf-lex.c -o lib/conf-lex.lo make: I.: command not found make: [lib/conf-lex.lo] error 127 (ignored) ----------------------------------------------------------- emerge info: Portage 2.0.51_rc9 (default-amd64-2004.2, gcc-3.3.4, glibc-2.3.4.20041006-r0, 2.6.8-gentoo-r10 x86_64) ================================================================= System uname: 2.6.8-gentoo-r10 x86_64 AMD Athlon(tm) 64 Processor 3000+ Gentoo Base System version 1.5.3 ccache version 2.3 [enabled] Autoconf: sys-devel/autoconf-2.59-r5 Automake: sys-devel/automake-1.8.5-r1 Binutils: sys-devel/binutils-2.15.92.0.2-r1 Headers: sys-kernel/linux26-headers-2.6.8.1-r1 Libtools: sys-devel/libtool-1.5.2-r5 ACCEPT_KEYWORDS="amd64 ~amd64" AUTOCLEAN="yes" CFLAGS="-O3 -ffast-math -mfpmath=sse -ftracer -fomit-frame-pointer -pipe" CHOST="x86_64-pc-linux-gnu" COMPILER="" CONFIG_PROTECT="/etc /usr/X11R6/lib/X11/xkb /usr/kde/2/share/config /usr/kde/3/share/config /usr/lib/mozilla/defaults/pref /usr/share/config /usr/share/texmf/dvipdfm/config/ /usr/share/texmf/dvips/config/ /usr/share/texmf/tex/generic/config/ /usr/share/texmf/tex/platex/config/ /usr/share/texmf/xdvi/ /var/qmail/control"CONFIG_PROTECT_MASK="/etc/gconf /etc/terminfo /etc/env.d" CXXFLAGS="-O2 -pipe" DISTDIR="/usr/portage/distfiles" FEATURES="autoaddcvs ccache distlocks sandox userpriv" GENTOO_MIRRORS="ftp://sunsite.cnlab-switch.ch/mirror/gentoo http://gentoo.oregonstate.edu http://www.ibiblio.org/pub/Linux/distributions/gentoo" MAKEOPTS="-j2" PKGDIR="/usr/portage/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="" SYNC="rsync://rsync.europe.gentoo.org/gentoo-portage" USE="X acpi alsa amd64 avi berkdb bitmap-fonts crypt cups encode foomaticdb gdbm gif gnome gtk gtk2 guile hbci imlib java jpeg leim libg++ libwww mikmod mozilla mpeg ncurses nls nogcj offensive oggvorbis opengl oss pam pdflib perl png python quicktime readline sdl slang smartcard speex spell ssl tcpd tetex truetype xml2 xmms xprint xv zlib video_cards_radeon"
Found solution in http://forums.gentoo.org/viewtopic.php?t=238146: "CC=gcc emerge lm-sensors" suceeds in installing lm-sensors. Now, go figure :-)
Closing as INVALID. Thanks for commenting :-)
I think this is a valid bug! I can confirm it. Saying you can fix it with "CC=gcc emerge lm-sensors" and then declaring it invalid isn't good enough. We need to make "emerge lm-sensors" work correctly.
Reopening as requested.
Is there anything we can do? Can one of the people that had the issue post the output of "emerge -v info" please? It seems like a sed went completely wrong or something. I have to understanding of why/how CC=gcc is fixing it...
Created attachment 42490 [details] emerge -v info
lm-sensors-2.8.8 also has this problem. Using CC=gcc does allow it to compile though. Note:I'm using a standard x86 not amd64.
Everything seems completely normal. Do you have any idea on what is going wrong where?
Created attachment 42515 [details] emerge -v info I'm also still experiencing this bug with 2.8.8. I have no idea whats going on but my first guess lately (after bug #65729) is to blame bash (i'm using 3.0-r7).
What I noticed, is that one of my computers where the compilation runs smoothly shows CC="gcc" in the output of "emerge -v info". However, the emerge -v info on the computer where compilation fails does not show a CC=.. line at all. So apparently the environment variable is not being set at all! (which of course explains why a CC=gcc ... makes things work). As to bash: the one where it does not work has bash-3.0-r7 It works on my machine which still has bash 3.0-r5. So bash might be involved here...
this is a bug in the ebuild i updated gcc-config not too long ago so that it doesnt export CC/CXX in the environment the lm-sensors incorrectly use 'emake CC=${CC}' ... that's always been wrong syntax ... the proper syntax is 'emake CC=$(tc-getCC)' after one inherit's the toolchain-funcs.eclass
*** Bug 68808 has been marked as a duplicate of this bug. ***
Fixed in CVS, the bugfix should reach the rsync mirrors within an hour. If you still have any problems, then please reopen this bug. Thanks!
