Not sure if this is on all amd64, but whenever i have icecream setup for distributed compiling, it creates a bad environment file due to the way gcc is linked (this happened on all three of my machines). Because of this, icecc could not compile on another machine, saying 'libc.so.6 no found'. icecc_create_env uses ldd to figure out what files to put in its environment, and copies /lib/libc.so.6 into it, however gcc really wants /lib64/libc.so.6 (probably due to the symlink from /lib64 to /lib). I am attaching a patch while solved this problem for me (emerged on all three machines : all three can now distribute compiles to the other two), however this patch is kindof hackish and im not sure if its the right way to go about it. Also havent had a chance to see if this works on x86 yet.
Created attachment 123353 [details, diff] icecc_create_env patch for grabbing /lib64/libc.so.6 Patch i used to get icecc_create_env to work right : just copy the current 0.7.14 ebuild to 0.7.14-r1 and add another epatch line.
hi! i created a liveCD for a AMD64 to help my new AMD64 X2 to compile kde/kdesvn and hat the same problem. I suffered the same symphtoms and applying the patch fixed the problem for me too, so the patch should get into portage by default?
Was tearing my hair out, thanks guys - maint, please include...
Created attachment 135238 [details, diff] Set of patch files The diff to icecc-create-env must be named "${FILESDIR}/${P}-use-lib64.patch"
I run in exactly the same problems. I can't figure out, why the packed lib/libc.so.6 can't be found on remote host. Maybe it's related to the fact, that the compilers on the remote system will be invoked in a chrooted enviroment. While a discussion in the irc we found, that e.g. the gcc seems to have compiled in a path to some libs with the prefix /lib64/..., but to libc.so.6 without. In contrast to the patch proposed by Kenneth Perry, i tryied to fix it a more universal way by patching the path names for the added libraries from "lib/.." to "lib64/...". This was quicky proven to work on my cluster. Just for savety (and without a real neeed, i think), this is ony applyed to amd64 enviroments.
Just checked the opensuse source rpm, would adding the --libdir= option to configure fix this? (As this is what opensuse does)
applied to icecream-0.9.0-r1, thanks
Thanks for version bumping, cleaning up and refurbishing the idea of my patch.
(In reply to comment #8) > Thanks for version bumping, cleaning up and refurbishing the idea of my patch. > Stephan Kulow (icecream maintainer) has said this patch won't be applied upstream, but would like if someone could help to find the cause of the bug: "OK, please provide us with some gentoo background: bash -x /usr/lib64/icecc/icecc-create-env /usr/bin/gcc /usr/bin/g++ Of course unpatched version of create-env" Could someone post the output of the above command? (I'm not on amd64 so can't test)
Created attachment 157063 [details] Log output of patched script "ice-create-env" As requested, i've attached the output of the unpatched version of "icecc-create-env" on (my) Gentoo amd64: bash -x /usr/lib64/icecc/icecc-create-env /usr/bin/gcc /usr/bin/gnv.unpatched.log 2>&1 Guido
Created attachment 157065 [details] Log output of unpatched script "ice-create-env" As requested, i've attached the output of the unpatched version of "icecc-create-env" on (my) Gentoo amd64: bash -x ~/icecc-create-env.unpatched /usr/bin/gcc /usr/bin/ice-create-env.unpatched.log 2>&1 Guido
Argh, sorry for the pasting mistake happened in the comments #10 and #11: The attachment with id=157063 is done with the *Gentoo-patched* version. The id=157065 is directly done with the unpatched upstream version out from the 0.9.0-tarball. Guido
(In reply to comment #9) > Stephan Kulow (icecream maintainer) has said this patch won't be applied > upstream, but would like if someone could help to find the cause of the bug: the cause is that the script uses /etc/ld.so.cache to determine the location of the libraries but doesn't include it in the archive But if you are in contact with him, ask him if he can include this patch: http://sources.gentoo.org/viewcvs.py/gentoo-x86/sys-devel/icecream/files/0.9.0-run-march-native-locally.patch?rev=1.1&view=raw
On Tue, Jun 17, 2008 at 12:17 PM, Stephan Kulow <coolo@kde.org> wrote: > Ouch, so /usr/bin/gcc is linked against /lib64/libc.so.6 and g++ linked > against /lib/libc.so.6 - is either a link to the other? > > Greetings, Stephan
No, gcc and g++ are both linked to "libc.so.6" without a path. The path of the library is then determined using /etc/ld.so.cache Looks like there has been a little confusion, I'll mail him a few lines to explain this in detail :)
