[gentoo-dev] rm `which gcc` && emerge -e world

[gentoo-dev] rm `which gcc` && emerge -e world

[Tomasz Mloduchowski]

[-- Attachment #1: Type: text/plain, Size: 771 bytes --]

Now, that I've got your attention. IMHO above should NOT fail - most of
the software in portage is already using ${HOST}-gcc instead and gcc
symlink is just a convenience.

But it does. In packages I will never suspect being nasty (qt, lynx) and
ones I would, but they shouldn't (fuse)

What is so important in that feature? Crosscompilation and distcc. 
For example, I have alpha-unknown-linux-gnu running as a distcc server
for x86 box. And, it does not work for those packages.

I got sick of filling 3 almost identical bug reports 
110040, 110086 and 110087 and I'm not even at half of emerge -uD world.

So, if you agree that it IS a problem, do the `rm` and run ebuilds you
maintain. You will save me another 10 or so unnended bugreports.

Tomasz

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] rm `which gcc` && emerge -e world

[Mike Frysinger]

On Friday 21 October 2005 11:12 pm, Tomasz Mloduchowski wrote:
> I got sick of filling 3 almost identical bug reports

please stop doing this

we are already playing with doing this in the wrapper itself so that 
compilation is transparent

i'd wager to say the majority of packages in portage run `gcc` and `g++` 
rather than ${CTARGET}-gcc
-mike
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] rm `which gcc` && emerge -e world

[Tomasz Mloduchowski]

[-- Attachment #1: Type: text/plain, Size: 582 bytes --]

On Sat, 2005-10-22 at 00:48 -0400, Mike Frysinger wrote
> we are already playing with doing this in the wrapper itself so that 
> compilation is transparent
> 
> i'd wager to say the majority of packages in portage run `gcc` and `g++` 
> rather than ${CTARGET}-gcc
So far, only 10% if packages failed for that reason. Things running
autotools should be safe. Problmes start when someone uses homebrew
makefile generators like qmake or Kbuild

Altough geoman raised a valid point with separate distcc server, I'm
glad something is being done to fix this issue.

Tomasz

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] rm `which gcc` && emerge -e world

[Diego 'Flameeyes' Pettenò]

[-- Attachment #1: Type: text/plain, Size: 714 bytes --]

On Saturday 22 October 2005 16:02, Tomasz Mloduchowski wrote:
> Things running autotools should be safe. 
*If* autotools are new enough. Things like nfs-utils are not safe.
I fixed a couple of them when I was trying eselect compiler because of a bug 
in it that caused me not to have gcc anymore.

> Problmes start when someone uses homebrew 
> makefile generators like qmake or Kbuild
That is usually quite simple to fix actually. alsa-driver for example is safe 
from that point of view (same problem as before with eselect compiler, so I 
fixed it "the hard way").

-- 
Diego "Flameeyes" Pettenò - http://dev.gentoo.org/~flameeyes/
Gentoo/ALT lead, Gentoo/FreeBSD, Video, AMD64, Sound, PAM, KDE

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] rm `which gcc` && emerge -e world

[Mike Frysinger]

On Saturday 22 October 2005 10:02 am, Tomasz Mloduchowski wrote:
> Altough geoman raised a valid point with separate distcc server, I'm
> glad something is being done to fix this issue.

you could also work around it by exporting CC and CXX before emerging to say 
'i686-pc-linux-gnu-gcc' and 'i686-pc-linux-gnu-g++'
-mike
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] rm `which gcc` && emerge -e world

[Stephen P. Becker]

Mike Frysinger wrote:
> On Saturday 22 October 2005 10:02 am, Tomasz Mloduchowski wrote:
> 
>>Altough geoman raised a valid point with separate distcc server, I'm
>>glad something is being done to fix this issue.
> 
> 
> you could also work around it by exporting CC and CXX before emerging to say 
> 'i686-pc-linux-gnu-gcc' and 'i686-pc-linux-gnu-g++'
> -mike

I'm not sure that works 100% of the time.

-Steve
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] rm `which gcc` && emerge -e world

[Mike Frysinger]

On Saturday 22 October 2005 03:11 pm, Stephen P. Becker wrote:
> Mike Frysinger wrote:
> > On Saturday 22 October 2005 10:02 am, Tomasz Mloduchowski wrote:
> >>Altough geoman raised a valid point with separate distcc server, I'm
> >>glad something is being done to fix this issue.
> >
> > you could also work around it by exporting CC and CXX before emerging to
> > say 'i686-pc-linux-gnu-gcc' and 'i686-pc-linux-gnu-g++'
> > -mike
>
> I'm not sure that works 100% of the time.

i didnt say it does, i meant it's a workaround for the non-autotools but 
make-based packages
-mike
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] rm `which gcc` && emerge -e world

[Stephen P. Becker]

Tomasz Mloduchowski wrote:
> Now, that I've got your attention. IMHO above should NOT fail - most of
> the software in portage is already using ${HOST}-gcc instead and gcc
> symlink is just a convenience.
> 
> But it does. In packages I will never suspect being nasty (qt, lynx) and
> ones I would, but they shouldn't (fuse)
> 
> What is so important in that feature? Crosscompilation and distcc. 
> For example, I have alpha-unknown-linux-gnu running as a distcc server
> for x86 box. And, it does not work for those packages.
> 
> I got sick of filling 3 almost identical bug reports 
> 110040, 110086 and 110087 and I'm not even at half of emerge -uD world.
> 
> So, if you agree that it IS a problem, do the `rm` and run ebuilds you
> maintain. You will save me another 10 or so unnended bugreports.
> 
> Tomasz

You can quite easily get around these problems by being clever with 
distccd and some strategically placed symlinks.  Simply, cd 
/usr/<foo>-unknown-linux-gnu/gcc-bin/<version>/, create symlinks in that 
directory that point cc, gcc, g++, and c++ to the appropriate 
${CHOST}-gcc, etc... binaries, and then use a script such as 
http://dev.gentoo.org/~geoman/mips-distcc.sh to start an arch specific 
distccd on its own port.  You can then use distcc-config to set your 
distcc hosts to host:port on the box you are compiling on.

This works great, and is pretty much 100% foolproof as far as I can tell.

-Steve
-- 
gentoo-dev@gentoo.org mailing list