Summary: | sys-devel/gcc-config-1.7 doesn't create /usr/bin/cc | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Yuta SATOH <nigoro.dev> |
Component: | [OLD] Core system | Assignee: | Gentoo Toolchain Maintainers <toolchain> |
Status: | RESOLVED FIXED | ||
Severity: | normal | CC: | bsd+disabled |
Priority: | Normal | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | All | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- |
not sure why but i have /usr/bin/cc here any package that executes `cc` for target code is broken. you should be fixing that independently of gcc-config behavior. http://git.overlays.gentoo.org/gitweb/?p=proj/gcc-config.git;a=commitdiff;h=968585e75310f95dd50a861eace5086996876f4b This commit dropped "cc wrapping". gcc-config-1.7 build wrapper list with this code: local new_wrappers=( $( uniq_wrapper_list "${CC_COMP_VERSION}" $( cd "${ROOT}${GCC_PATH}" || exit 1 echo * ) ) ) but we don't have "cc" in the gcc path, so that "cc" is not properly wrapped. ls /usr/x86_64-pc-linux-gnu/gcc-bin/4.5.3 aot-compile gcc gfortran gkeytool gserialver x86_64-pc-linux-gnu-cpp x86_64-pc-linux-gnu-gfortran c++ gccbug gij gnative2ascii gtnameserv x86_64-pc-linux-gnu-g++ cpp gcj gjar gorbd jcf-dump x86_64-pc-linux-gnu-gcc g++ gcj-dbtool gjarsigner grmic jv-convert x86_64-pc-linux-gnu-gcc-4.5.3 gappletviewer gcjh gjavah grmid rebuild-gcj-db x86_64-pc-linux-gnu-gcj gc-analyze gcov gjdoc grmiregistry x86_64-pc-linux-gnu-c++ x86_64-pc-linux-gnu-gcjh This is problem not only on FreeBSD but also on the other platform. (In reply to comment #2) > any package that executes `cc` for target code is broken. you should be > fixing that independently of gcc-config behavior. isnt 'cc' the fallback when bootstraping / changing CHOST ? i hit this when trying to make stages for e.g. i386-something from a i686-something seed. Any comments from vapier? I believe gcc-config should be fixed to have cc linked. Even if our package should be and would be call gcc, "make" defaults to use "cc". This missing cc link lead to users' make command failure. Steps to see how cc is called from make: $ cd /tmp $ touch foo.c $ make foo cc foo.c -o foo <snip> make's default compiler being cc is exactly why you need to fix packages that don't honor the CC env var. This just exposes those bugs. No comment on bootstrapping, I don't know. On second thought I think I missed your point. People probably expect make to work outside of portage too. I imagine this could break some scripts. I also noticed your example actually worked for me because ccache provides a cc symlink, so now we're inconsistent. (In reply to comment #4) there is probably something else going wrong there, but i don't care to track it down as it probably doesn't matter much should be all set now in the tree; thanks for the report! Commit message: Fix installation of cc/f77 helpers http://sources.gentoo.org/sys-devel/gcc-config/gcc-config-1.7.1.ebuild?rev=1.1 |
Some packages are to call cc command at compile time. However, gcc-config-1.7 doesn't create it. Reproducible: Always Steps to Reproduce: 1. rm /usr/bin/cc /usr/bin/gcc 2. ACCEPT_KEYWORDS=~x86-fbsd emerge sys-devel/gcc-config 3. gcc-config 1 Actual Results: sys-devel/gcc-config-1.7 results) # ls -1 /usr/bin/cc /usr/bin/gcc ls: /usr/bin/cc: No such file or directory /usr/bin/gcc sys-devel/gcc-config-1.6 results) # ls -1 /usr/bin/cc /usr/bin/gcc /usr/bin/cc /usr/bin/gcc FYI, app-arch/unzip results) >>> Emerging (1 of 1) app-arch/unzip-6.0-r1 >>> Compiling source in /var/tmp/portage/app-arch/unzip-6.0-r1/work/unzip60 ... gmake -j5 -f unix/Makefile bsd gmake unzips CF="-O2 -pipe -I. -Ibzip2 -DUNIX -DBSD" gmake[1]: Entering directory `/var/tmp/portage/app-arch/unzip-6.0-r1/work/unzip60' cc -c -O2 -pipe -I. -Ibzip2 -DUNIX -DBSD unzip.c gmake[1]: cc: Command not found gmake[1]: *** [unzip.o] Error 127 gmake[1]: Leaving directory `/var/tmp/portage/app-arch/unzip-6.0-r1/work/unzip60' gmake: *** [_bsd] Error 2 emake failed