| Summary: | binutils not in PATH, /etc/init.d/functions.sh from baselayout/openrc missing, gcc cant compile, ... | ||
|---|---|---|---|
| Product: | Gentoo Linux | Reporter: | Michał Deszcz <descyk> |
| Component: | [OLD] GCC Porting | Assignee: | Gentoo Linux bug wranglers <bug-wranglers> |
| Status: | VERIFIED CANTFIX | ||
| Severity: | normal | CC: | wmm |
| Priority: | High | ||
| Version: | unspecified | ||
| Hardware: | x86 | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
| Attachments: |
build.log
/var/tmp/portage/sys-devel/gcc-4.4.2/work/build/config.log |
||
|
Description
Michał Deszcz
2009-11-09 23:20:23 UTC
Created attachment 209780 [details]
build.log
checking for C compiler default output file name... configure: error: in `/var/tmp/portage/sys-devel/gcc-4.4.2/work/build': configure: error: C compiler cannot create executables See `config.log' for more details. This is a generic error message. Can you attach the config.log you find in that directory? Created attachment 209807 [details]
/var/tmp/portage/sys-devel/gcc-4.4.2/work/build/config.log
Yes, here You are.
Bit atypical: i686-pc-linux-gnu-gcc: error trying to exec 'as': execvp: No such file or directory Is everything alright with your PATH/binutils ? verify your binutils is installed, selected (binutils-config), and your profile env is pointing to the right things (In reply to comment #5) > verify your binutils is installed, selected (binutils-config), and your profile > env is pointing to the right things > No such file or directory! [code] g2_poligon / # binutils-config /usr/bin/binutils-config: line 19: /etc/init.d/functions.sh: Nie ma takiego pliku ani katalogu binutils-config: Could not source /etc/init.d/functions.sh! [/code] that file is provided by baselayout/openrc. if that's missing, your system is severely screwed. check those important core packages are actually installed. I had exactly the same issue. IMO it started by upgrading baselayout to 2.0.1, which removed (AFAIK) /sbin/functions.sh and probably much more. I didn't have openrc installed before and I couldn't emerge it anymore due to all these missing files. This happened just during normal update process (which I haven't done for some time). I was able to fix it like this: 1. the /usr/bin/as link leads (for me) to /usr/x86_64-pc-linux-gnu/binutils-bin/2.18/as. But I found only 2.20 (binutils version) directory in /usr/x86_64-pc-linux-gnu/binutils-bin/. So cd /usr/x86_64-pc-linux-gnu/binutils-bin/ && ln -s 2.20 2.18 fixes the compilation issue and you can emerge again. 2. emerge openrc. That will fix the funcitons.sh issue and now you can use binutils-config to set the new binutils to properly point to the new version. Thanks to guys on #gentoo for help. cheers lukash (In reply to comment #8) > I had exactly the same issue. IMO it started by upgrading baselayout to 2.0.1, > which removed (AFAIK) /sbin/functions.sh and probably much more. I didn't have > openrc installed before and I couldn't emerge it anymore due to all these > missing files. > > This happened just during normal update process (which I haven't done for some > time). > > I was able to fix it like this: > 1. the /usr/bin/as link leads (for me) to > /usr/x86_64-pc-linux-gnu/binutils-bin/2.18/as. But I found only 2.20 (binutils > version) directory in /usr/x86_64-pc-linux-gnu/binutils-bin/. So cd > /usr/x86_64-pc-linux-gnu/binutils-bin/ && ln -s 2.20 2.18 fixes the compilation > issue and you can emerge again. > > 2. emerge openrc. That will fix the funcitons.sh issue and now you can use > binutils-config to set the new binutils to properly point to the new version. > > Thanks to guys on #gentoo for help. > > cheers > lukash > It's not the same :( My instaled binutils is 2.18 and the /usr/bin/as leads to /usr/bin/i686-pc-linux-gnu-as. I changed it to /usr/i686-pc-linux-gnu/binutils-bin/2.18/as, but the difference was no. Ma baselayout is 2.0.1, but I have not instaled sysvinit (becouse I had to unmerge it before I'll install openrc), and openrc I cannot compile :/ So, I must to fix the compilation problem to do something else. But how? Michal, did you manage to recover your system yet? If not, please give more details on what happened before it broke -- for instance, how did baselayout-2.0.1 get installed without openrc being installed yet? Maybe you should revert to baselayout-1.12.13 to get things building again, since it does not depend on openrc. I was downgrade from "~x86" to stable version, but someones packages were not wanted to compile, I used --skip-first option. I don't remenber this packages, but now, I think, it was a reason. Ok, I can see how you might run into problems, since upgrades are the direction that developers focus on, especially for large changes like switching to openrc. How about the suggestion to downgrade baselayout next, does that work for you? I can't downgrade, becouse I can't compile anything, so it don't work. Yes, I had also a problem when downgrading from ~x86_64 to the stable branch. I've solved it by manually correcting all the symlinks in: /usr/x86_64-pc-linux-gnu/bin (which pointed on the non-existing binutils) and copying "functions.sh" from the live-CD So, to the maintainers of binutils package! Is it possible to check the correctness of the symlinks somehow automatically when installing a new version??? May be we should change the bug-title? It seems to when downgrading one have to unmask: glibc and binutils anyway, because downgrading of glibc is not supported and it depends on binutils. Downgrading from ~arch to arch isn't really supported, so if things go wrong there's not much we can do. The best way to downgrade is to remove ACCEPT_KEYWORDS from make.conf, keyword all packages in /etc/portage/package.keywords with the exact installed version and then slowly let updates catch up as things are marked stable. This system I removed and the problem too. Thenk You for help Mrs. ;) Even though this may be obsolete, I would like to document that I also had this error in comment #4 after upgrading an outdated x86 system from livecd in a chrooted environment. I further had "kern-clo-test"-errors, emerge errors with failing wget in the emerge process and links not working due to unmerged blockers, all kind of queer errors I never had before. It was severe, as I was unable to compile anything, not even my kernel, and I was unable to emerge glibc, neither as source nor as binary. At times, even emerge failed due to gcc errors. After having searched many bug and other weblinks without luck, poking around via trial and error, comment #4 and #5 was my life saver. Even though I use gentoo for a long time now, I have a long history of outdated slow systems due to unsolvable emerge errors cascading to very outdated systems. I did a "binutils-config -l", with a "i686-pc-linux-gnu-2.18" as output, followed by "binutils-config -c" with output of " [1] i686-pc-linux-gnu-2.19.1", and then successfully tried "binutils-config 1", which solved my problems: * Switching to i686-pc-linux-gnu-2.19.1 ... [ ok ] >>> Regenerating /etc/ld.so.cache... Just run "source /etc/profile" afterwards. Since these simple commands I can compile again and my "emerge -vun system" in a chrooted environment with the flag "--getbinpkg" is working perfectly. After a successful update of my system I will return back to compile without "--getbinpkg", because I hope to run with a fast distcc server. Compiling the kernel with distcc also works again. Furthermore I also had the errors posted in comment #6. In my chrooted environment I had missing shell scripts in /etc/init.d/ , not only the functions.sh, other also, even execvp-errors, "as" missing. I have done the following: I have saved my data in most config dirs like /etc and world config file. I have important data lying around elsewhere and was unable to remove it from the system without very much effort so I didn't just format the partition and start all over. Therefore, I then imported a new portage-latest and stage3-latest. Before installing stage3-latest, I installed it to another subdir of my choice, I renamed new config files that would overwrite mine to *.orig and repacked the stage3 file to a new name and then imported that. At /etc I edited and merged .orig and my own config files together. At some time in the update process some libs and other data were deleted or had to be removed due to blocking issues. Wherever possible I copied missing libs and files from the current livecd to my new system, when they were missing due to file conflicts and unmerge processes. Eventually my system is now somewhat stable and up-to-date. My PIII@500MHz is somewhat clean now (I hope), so I guess I'll do it again on my PI@133MHz. I've decided to post this here, so in case other users in my rare situation can see how I fixed this issue. |
