Mailing List Archive

What about gcc-config - will that work?
>
> From: Sven Köhler <skoehler@upb.de>
> Date: 2006/06/16 Fri PM 03:10:08 EDT
> To: gentoo-dev@lists.gentoo.org
> Subject: [gentoo-dev] using specific gcc-version in ebuild
>
>

--
gentoo-dev@gentoo.org mailing list

On Friday 16 June 2006 15:10, Sven Köhler wrote:
> i just wanted to ask, if the is an eclass or something else, that
> enables me to temporarly select a certain gcc-version? or perhaps just
> finding the path to the gcc and g++ executables of a specific
> gcc-versions (like gcc-3.*)?

no, there isnt ... while you may want to do this in your own ebuilds to work
around problems, the answer is "not a chance" for anything going into the
tree

> some software, like qemu and others, are simply not compatible with gcc
> 4.x and they will not become compatible due to severe conceptional issues.

then they stay broken ... add a warning to the ebuild if `gcc-major-version`
is "4" (see toolchain-funcs.eclass)
-mike

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Forcing a change in your gcc version for compiling is less then
optimal. I don't believe the eclass has anything in it that will help
in what you are trying to do. I would probably do a pkg_setup with a
check for the version of gcc if it isn't a 3.* version then you exit
building and give the reason for this...This would probably be the
best way to do it, at this point.

brettholcomb@bellsouth.net wrote:
> What about gcc-config - will that work?
>> From: Sven Köhler <skoehler@upb.de> Date: 2006/06/16 Fri PM
>> 03:10:08 EDT To: gentoo-dev@lists.gentoo.org Subject:
>> [gentoo-dev] using specific gcc-version in ebuild
>>
>>
>


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.3 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFEkwcUSENan+PfizARAjLdAJ9u6zhasuWe4AT5x3+rcOAMlgqovwCeLPNf
NLU57K0Bl7uuneLhujKRLck=
=nSTb
-----END PGP SIGNATURE-----

--
gentoo-dev@gentoo.org mailing list

Yeah, I missed the context! I was not thinking about an ebuild.

>
> From: Joshua Jackson <tsunam@gentoo.org>
> Date: 2006/06/16 Fri PM 03:31:32 EDT
> To: gentoo-dev@lists.gentoo.org
> Subject: Re: [gentoo-dev] using specific gcc-version in ebuild
>
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Forcing a change in your gcc version for compiling is less then
> optimal. I don't believe the eclass has anything in it that will help
> in what you are trying to do. I would probably do a pkg_setup with a
> check for the version of gcc if it isn't a 3.* version then you exit
> building and give the reason for this...This would probably be the
> best way to do it, at this point.
>
> brettholcomb@bellsouth.net wrote:
> > What about gcc-config - will that work?
> >> From: Sven Köhler <skoehler@upb.de> Date: 2006/06/16 Fri PM
> >> 03:10:08 EDT To: gentoo-dev@lists.gentoo.org Subject:
> >> [gentoo-dev] using specific gcc-version in ebuild
> >>
> >>
> >
>
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.3 (GNU/Linux)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
>
> iD8DBQFEkwcUSENan+PfizARAjLdAJ9u6zhasuWe4AT5x3+rcOAMlgqovwCeLPNf
> NLU57K0Bl7uuneLhujKRLck=
> =nSTb
> -----END PGP SIGNATURE-----
>
> --
> gentoo-dev@gentoo.org mailing list
>
>

--
gentoo-dev@gentoo.org mailing list

Sven Köhler wrote:
>>> some software, like qemu and others, are simply not compatible with gcc
>>> 4.x and they will not become compatible due to severe conceptional issues.
>>>
>> then they stay broken ... add a warning to the ebuild if `gcc-major-version`
>> is "4" (see toolchain-funcs.eclass)
>>
>
> Hmm, but ...
>
> there is the possibility to have multiple gcc versions installed. So why
> not set CC and/or CXX variables inside the ebuild, and then compile the
> app with the "right" gcc-version?
>
> At this point, it just bugs me, that gentoo is staying below its potential.
>
> Well, hmmm, you might want to say, that there will be trouble because of
> applications/libraries linked to different libstdc++ versions - or
> something else.
>
> I'm always willing to learn, but this really bugs me, because gentoo
> really has potential for what's needed in this situation.
>
>
Well, the problem here is that compiling some packages with one version
of GCC and others with another version of GCC (on the same system) is
asking for trouble. This means that ebuilds shouldn't change the GCC
version in use. If the user wants to try it and see if it works, let
them have at it, but don't do it automatically - it *will* eventually
break someone's system (maybe not with 3.4+4.0/4.1, but who knows with
future versions...remember the migration from GCC 3.3 to 3.4?).

--Arek

P.S. Who knows...eventually these incompatible packages might just make
the move to GCC 4 (possibly on a major update). Until they do, tho,
they'll just have to be broken (which is a shame...I like qemu).
--
gentoo-dev@gentoo.org mailing list

On Fri, 16 Jun 2006 15:30:06 -0400
Mike Frysinger <vapier@gentoo.org> wrote:

> On Friday 16 June 2006 15:10, Sven Köhler wrote:
> > some software, like qemu and others, are simply not compatible with
> > gcc 4.x and they will not become compatible due to severe
> > conceptional issues.
>
> then they stay broken ... add a warning to the ebuild if
> `gcc-major-version` is "4" (see toolchain-funcs.eclass)

I've been thinking about this recently. What qemu does is compile a C
implementation of the target processor's instruction set into an object
file when qemu is built, then at run-time (JIT time) it cut-n-pastes
bits of that object file when it "compiles" the target executable into
native code that can be executed directly in the emulator. This is
pretty cool, as it means you have a cross-platform target emulator that
is fast because it leverages the compiler to write the emulation code,
without having to maintain separate implementations for each target.

However it does rely on the ability to snip the function
prologue/epilogue reliably so you can stitch stuff together (in
particular the return instruction is eliminated), and with gcc-4 this is
no longer possible because the return is not always and only at the end
of the function. I think the change to gcc that causes this is one of
the reasons the major revision number was increased.

The reason for describing this is to illustrate that qemu is not
"broken" as such; it just relies on implementation detail of the pre-4
gcc series. Since gcc-4 doesn't provide any option to force code
generation to fit the requirements of qemu, the compilation of the
affected code must use gcc-3 (which it does with a very specific set
of CFLAGS). Note; the majority of qemu can be compiled with gcc-4 just
fine, however the target implementation objects have to be built with
gcc-3 because gcc-4 does not provide an option to get the old gcc-3
behaviour.

Since we already have slotted gcc working just fine, it seems
reasonable to me that we could support packages requiring the existence
of more than one compiler version (although I'm not sure portage
DEPENDs will cope - I'm guessing:

DEPEND="<sys-devel/gcc-4
>=sys-devel/gcc-4"

won't be interpreted to mean both a pre-4 and a post-4 compiler are
required).

Portage DEPENDs aside, it would be relatively easy to provide a
function to return the latest 3-series compiler. We already have
symlinks installed in /usr/bin (e.g. i686-pc-linux-gnu-gcc-3.4.6) -
caveat that they don't use the wrapper, although that may not matter.

Absent the DEPEND functionality, we can still go quite a way just by
supplying a suitable function or functions in toolchain-funcs.eclass.
The affected packages can use them in pkg_setup to check for existence
and abort if they're not available without requiring the user to change
the system default compiler. The only loss is that the user doesn't
find out about the missing dependency until the package is actually
merged, rather than at the beginning of an 'emerge world'.


Perhaps details should be taken off-list, if we're to think about this
seriously.

--
Kevin F. Quinn

Hi Sven

п'ятниця, 16. червень 2006 21:10, Sven Köhler Ви написали:
> i just wanted to ask, if the is an eclass or something else, that
> enables me to temporarly select a certain gcc-version? or perhaps just
> finding the path to the gcc and g++ executables of a specific
> gcc-versions (like gcc-3.*)?
Please take a look at gnat.eclass (you will need to check eselect-gnat too
and, possibly, gnatbuild.eclass as well). These do not do anything about gcc
or any system-wide changes at all, but do something resembling with gnat, as
far as its libs are concerned.

However please note, it is better to avoid this unless you absolutely must. In
your case it is porbably best (at present state of portage) to just check for
the active version of gcc in pkg_setup and abort if it is not the one you
need. You definitely cannot run gcc-config from within scr_* funcs and it is
better not tu switch gcc behind user's back, even though you technically can
in pkg_* (but as portage people do not expect you to do so, it may start
failing in weird ways in the future)..

George

--
gentoo-dev@gentoo.org mailing list

On Friday 16 June 2006 20:10, Kevin F. Quinn wrote:
> The reason for describing this is to illustrate that qemu is not
> "broken" as such; it just relies on implementation detail of the pre-4
> gcc series.

then it's broken by design ... sure the idea about how qemu goes about its
emulation is pretty goddamn cool, but gcc has never said that you can rely on
certain behavior
-mike

>> some software, like qemu and others, are simply not compatible with gcc
>> 4.x and they will not become compatible due to severe conceptional issues.
>
> then they stay broken ... add a warning to the ebuild if `gcc-major-version`
> is "4" (see toolchain-funcs.eclass)

Hmm, but ...

there is the possibility to have multiple gcc versions installed. So why
not set CC and/or CXX variables inside the ebuild, and then compile the
app with the "right" gcc-version?

At this point, it just bugs me, that gentoo is staying below its potential.

Well, hmmm, you might want to say, that there will be trouble because of
applications/libraries linked to different libstdc++ versions - or
something else.

I'm always willing to learn, but this really bugs me, because gentoo
really has potential for what's needed in this situation.

> I've been thinking about this recently. What qemu does is compile a C
> implementation of the target processor's instruction set into an object
> file when qemu is built, then at run-time (JIT time) it cut-n-pastes
> bits of that object file when it "compiles" the target executable into
> native code that can be executed directly in the emulator. This is
> pretty cool, as it means you have a cross-platform target emulator that
> is fast because it leverages the compiler to write the emulation code,
> without having to maintain separate implementations for each target.
>
> However it does rely on the ability to snip the function
> prologue/epilogue reliably so you can stitch stuff together (in
> particular the return instruction is eliminated), and with gcc-4 this is
> no longer possible because the return is not always and only at the end
> of the function. I think the change to gcc that causes this is one of
> the reasons the major revision number was increased.
>
> The reason for describing this is to illustrate that qemu is not
> "broken" as such; it just relies on implementation detail of the pre-4
> gcc series. Since gcc-4 doesn't provide any option to force code
> generation to fit the requirements of qemu, the compilation of the
> affected code must use gcc-3 (which it does with a very specific set
> of CFLAGS). Note; the majority of qemu can be compiled with gcc-4 just
> fine, however the target implementation objects have to be built with
> gcc-3 because gcc-4 does not provide an option to get the old gcc-3
> behaviour.

You take the words out of my mouth. That is exactly, what i'm after.

Actually i know, that there are aware of problems that may be caused by
using different compilers for different parts of software. But for qemu,
this is possibly a must.

While gentoo-ebuilds will still complain and force people to switch gcc
by hand, other distros may simply offer a qemu built with a different
gcc-version than the system-wide one.

> Since we already have slotted gcc working just fine, it seems
> reasonable to me that we could support packages requiring the existence
> of more than one compiler version (although I'm not sure portage
> DEPENDs will cope - I'm guessing:
>
> DEPEND="<sys-devel/gcc-4
> >=sys-devel/gcc-4"
>
> won't be interpreted to mean both a pre-4 and a post-4 compiler are
> required).

I think, this does what you don't expect it to do.

I remember a bug, where a maintainer wanted to depend on a package, but
only a certain version-interval. He used exactly something like you
wrote it above. In the end, two versions of the package were installed,
and some people agreed on the necessity for a syntax for a
version-interval. (which is still not in portage 2.1 afaik)

> then it's broken by design ... sure the idea about how qemu goes about its
> emulation is pretty goddamn cool, but gcc has never said that you can rely on
> certain behavior

very right!

but you cannot change the world :-(