Home | Docs | Forums | Lists | Bugs | Planet | Store | GMN | Get Gentoo!

Full Text Bug Listing

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 an attachment (id=123353) [details]
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 an attachment (id=135238) [details]
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 an attachment (id=157063) [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 /usr/lib64/icecc/icecc-create-env  /usr/bin/gcc
/usr/bin/gnv.unpatched.log 2>&1

Guido

Created an attachment (id=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 :)