Hi folks,


I'm just installing qemu, which requires gcc-3.x for building.
The current breaks are very ugly, IMHO.

So I'm proposing to add the old gcc-3.x as depedency to qemu,
at least as long as it doesn't build w/ newer gcc.

What do you think about this ?


cu
--
---------------------------------------------------------------------
Enrico Weigelt == metux IT service - http://www.metux.de/
---------------------------------------------------------------------
Please visit the OpenSource QM Taskforce:
http://wiki.metux.de/public/OpenSource_QM_Taskforce
Patches / Fixes for a lot dozens of packages in dozens of versions:
http://patches.metux.de/
---------------------------------------------------------------------
--
gentoo-dev@lists.gentoo.org mailing list

В В�к, 04/05/2008 в 21:48 +0200, Enrico Weigelt пишет:
> I'm just installing qemu, which requires gcc-3.x for building.
> The current breaks are very ugly, IMHO.
>
> So I'm proposing to add the old gcc-3.x as depedency to qemu,
> at least as long as it doesn't build w/ newer gcc.
>
> What do you think about this ?

How do you suppose to change gcc version portage uses on-the-fly?
Please, answer trough bugzilla where most bug reports/feature requests
should normally go.

--
Peter.

Enrico Weigelt wrote:
I'm just installing qemu, which requires gcc-3.x for building.
The current breaks are very ugly, IMHO.


So I'm proposing to add the old gcc-3.x as depedency to qemu,
at least as long as it doesn't build w/ newer gcc.


Hi Enrico, it is usually a good idea to search through the Bugzilla
before asking for some feature, chances are that it has been already
requested (in this case, you're looking for bug 190102). FYI, at least
some of qemu's features were ported to gcc4 -- for example, see the
kvm-qemu ebuild from bug 157987.


Cheers,
-jkt

--
cd /local/pub && more beer > /dev/mouth
--
gentoo-dev@lists.gentoo.org mailing list

* Peter Volkov <pva@gentoo.org> schrieb:
> ?? ??????, 04/05/2008 ?? 21:48 +0200, Enrico Weigelt ??????????:
> > I'm just installing qemu, which requires gcc-3.x for building.
> > The current breaks are very ugly, IMHO.
> >
> > So I'm proposing to add the old gcc-3.x as depedency to qemu,
> > at least as long as it doesn't build w/ newer gcc.
> >
> > What do you think about this ?
>
> How do you suppose to change gcc version portage uses on-the-fly?

* add an small gcc3-wrapper script/symlink (eg. /usr/bin/gcc-3)
* rewrite the qemu ebuild to properly set $CC, etc.

> Please, answer trough bugzilla where most bug reports/feature requests
> should normally go.

Is there already an open bug on this ?


BTW: even with gcc-3.x qemu fails to build. this has been reported
multiple times, but none of the suggestions worked


cu
--
---------------------------------------------------------------------
Enrico Weigelt == metux IT service - http://www.metux.de/
---------------------------------------------------------------------
Please visit the OpenSource QM Taskforce:
http://wiki.metux.de/public/OpenSource_QM_Taskforce
Patches / Fixes for a lot dozens of packages in dozens of versions:
http://patches.metux.de/
---------------------------------------------------------------------
--
gentoo-dev@lists.gentoo.org mailing list

On 5/5/08, Jan Kundrát <jkt@gentoo.org> wrote:
> Hi Enrico, it is usually a good idea to search through the Bugzilla before
> asking for some feature, chances are that it has been already requested (in
> this case, you're looking for bug 190102). FYI, at least some of qemu's
> features were ported to gcc4 -- for example, see the kvm-qemu ebuild from
> bug 157987.

I also waiting for gcc-4 enabled qemu for long time...
The problem that "emerge --emptytree world" will not work when
packages are compiled in different gcc versions.
The kvm-qemu is not relevant if you don't have the hardware.

One solution I saw is to compile gcc-3 as part of the qemu build
process, and make the qemu use this gcc-3 instance. This way you can
have qemu up and running while the system is configured for gcc-4.

It is very disappointing that upstream does not allow gcc-4
configuration so long after gcc-4 release.

Alon.

On Montag, 5. Mai 2008, Peter Volkov wrote:
> В В�к, 04/05/2008 в 21:48 +0200, Enrico Weigelt пишет:
> > I'm just installing qemu, which requires gcc-3.x for building.
> > The current breaks are very ugly, IMHO.
> >
> > So I'm proposing to add the old gcc-3.x as depedency to qemu,
> > at least as long as it doesn't build w/ newer gcc.
> >
> > What do you think about this ?
>
> How do you suppose to change gcc version portage uses on-the-fly?
> Please, answer trough bugzilla where most bug reports/feature requests
> should normally go.

I suggest something like this:
Get correct path of gcc-3 executable, then supply this with $CC to make.


Code may look like this:

# get last one of sorted list
for t in $(ls -1 /usr/bin/gcc-3*|sort); do
p=$t
done
einfo "Using $p for compiling."
emake CC=$p

Matthias
--
gentoo-dev@lists.gentoo.org mailing list

Enrico Weigelt wrote:

Hi folks,


I'm just installing qemu, which requires gcc-3.x for building.
The current breaks are very ugly, IMHO.


So I'm proposing to add the old gcc-3.x as depedency to qemu,
at least as long as it doesn't build w/ newer gcc.


What do you think about this ?



that qemu is a sore exception, you should help upstream porting to gcc-4
if you have time, every people concerned should.


Nowadays most of the work left to be done is _pretty_ boring and
_pretty_ simple so everybody could help patching ^^


lu

--

Luca Barbato
Gentoo Council Member
Gentoo/linux Gentoo/PPC
http://dev.gentoo.org/~lu_zero

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

Matthias Schwarzott wrote:
> Code may look like this:
>
> # get last one of sorted list
> for t in $(ls -1 /usr/bin/gcc-3*|sort); do
use teh globs, luke
for t in /usr/bin/gcc-3*; do # will already do this, sorting according to
LC_COLLATE order (set to C or POSIX [same thing] for ebuild.) There's no
need to step through every one either:
t=(/usr/bin/gcc-3*); p=${t[@]: -1}; unset t # get rid of array storage
(using same var for both, eg t=${t[@]: -1} only sets the first cell; the
rest of the array is still live. var is a synonym for var[0] in BASH.)

set -- *
t=${@: -1} # works here as well but dunno if that applies to all sh (the -1
expansion, not the set.) In any event not needed in BASH since arrays make
our life so much easier

cf: /msg greybot ls and http://wooledge.org/mywiki/glob -- remember you can
do, eg: for i in portage/*/*foo*/*.ebuild
or a more common example: for f in */*/.jpg
It's not find, but it is efficient and filename-safe.

Regards,
steveL.

(Please, no complaints about not using spaces in filenames, there's no
telling where your script could be used-- if it's written correctly.
Subshells and externals as well; why fork and waste resources we don't have
to?)


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

On Samstag, 10. Mai 2008, Steve Long wrote:
> Matthias Schwarzott wrote:
> > Code may look like this:
> >
> > # get last one of sorted list
> > for t in $(ls -1 /usr/bin/gcc-3*|sort); do
>
> use teh globs, luke
> for t in /usr/bin/gcc-3*; do # will already do this, sorting according to
> LC_COLLATE order (set to C or POSIX [same thing] for ebuild.) There's no
> need to step through every one either:
> t=(/usr/bin/gcc-3*); p=${t[@]: -1}; unset t # get rid of array storage
> (using same var for both, eg t=${t[@]: -1} only sets the first cell; the
> rest of the array is still live. var is a synonym for var[0] in BASH.)
>
> set -- *
> t=${@: -1} # works here as well but dunno if that applies to all sh (the -1
> expansion, not the set.) In any event not needed in BASH since arrays make
> our life so much easier
>
Well, you want it compact, without loops.
Here is it:

set -- /usr/bin/gcc-3*
Get first entry: CC="$1"
Get last entry: eval CC="${$#}"

Regards
Matthias
--
gentoo-dev@lists.gentoo.org mailing list

Matthias Schwarzott wrote:
> Well, you want it compact, without loops.
> Here is it:
>
> set -- /usr/bin/gcc-3*
> Get first entry: CC="$1"
> Get last entry: eval CC="${$#}"
>
Nice one, yeah I thought : splitting was posix silly me
I still shy clear of eval for general use and you have to go thru
contortions with sh, so I'll stick with BASH arrays and "syntactic sugar"
which gets twisted enough as it is.


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