| 1 |
Sven Köhler wrote: |
| 2 |
>>> some software, like qemu and others, are simply not compatible with gcc |
| 3 |
>>> 4.x and they will not become compatible due to severe conceptional issues. |
| 4 |
>>> |
| 5 |
>> then they stay broken ... add a warning to the ebuild if `gcc-major-version` |
| 6 |
>> is "4" (see toolchain-funcs.eclass) |
| 7 |
>> |
| 8 |
> |
| 9 |
> Hmm, but ... |
| 10 |
> |
| 11 |
> there is the possibility to have multiple gcc versions installed. So why |
| 12 |
> not set CC and/or CXX variables inside the ebuild, and then compile the |
| 13 |
> app with the "right" gcc-version? |
| 14 |
> |
| 15 |
> At this point, it just bugs me, that gentoo is staying below its potential. |
| 16 |
> |
| 17 |
> Well, hmmm, you might want to say, that there will be trouble because of |
| 18 |
> applications/libraries linked to different libstdc++ versions - or |
| 19 |
> something else. |
| 20 |
> |
| 21 |
> I'm always willing to learn, but this really bugs me, because gentoo |
| 22 |
> really has potential for what's needed in this situation. |
| 23 |
> |
| 24 |
> |
| 25 |
Well, the problem here is that compiling some packages with one version |
| 26 |
of GCC and others with another version of GCC (on the same system) is |
| 27 |
asking for trouble. This means that ebuilds shouldn't change the GCC |
| 28 |
version in use. If the user wants to try it and see if it works, let |
| 29 |
them have at it, but don't do it automatically - it *will* eventually |
| 30 |
break someone's system (maybe not with 3.4+4.0/4.1, but who knows with |
| 31 |
future versions...remember the migration from GCC 3.3 to 3.4?). |
| 32 |
|
| 33 |
--Arek |
| 34 |
|
| 35 |
P.S. Who knows...eventually these incompatible packages might just make |
| 36 |
the move to GCC 4 (possibly on a major update). Until they do, tho, |
| 37 |
they'll just have to be broken (which is a shame...I like qemu). |
| 38 |
-- |
| 39 |
gentoo-dev@g.o mailing list |
Archives