1 |
On Tue, 11 Oct 2011 03:27:04 +0000 (UTC) |
2 |
Duncan <1i5t5.duncan@×××.net> wrote: |
3 |
|
4 |
> The problem generally occurs when I decided I've waited long enough for a |
5 |
> long released upstream gcc (4.x.1 and often 4.x.2 are released already!) |
6 |
> to get unmasked even to ~arch. Of course, having been thru this cycle a |
7 |
> few times now, I well understand the reasons why it takes so long for |
8 |
> Gentoo to bump gcc even to ~arch, and accept that I'll often have to dig |
9 |
> thru bugs (often with patches attached for months, with no visible |
10 |
> action, if I were to complain about Gentoo it'd be about the maintainers |
11 |
> of those packages letting those bugs sit, or of packages that should be |
12 |
> put up for someone else to maintain if the maintainers can no longer |
13 |
> handle it, not about the efforts of the toolchain folks) and drop patches |
14 |
> in /etc/portage/patches/* and/or overlay a package if the ebuild itself |
15 |
> needs patched, and that a few packages might not yet have patches |
16 |
> available. That's not the problem. |
17 |
|
18 |
I try to overcome that obstacle with the gcc-porting overlay. I try to stick |
19 |
all the patches that haven't been applied to the main tree in there. (try |
20 |
being the key word - I really dropped the ball this release cycle as I |
21 |
was graduating and then got stuck working 80hr weeks for a few months.) |
22 |
|
23 |
> The problem is often cmake related. Since cmake is C++, once I rebuild |
24 |
> it against the new gcc, it tends to refuse to run if I switch to the old |
25 |
> gcc. Which means I'm SOL for the cmake-based package in question if it |
26 |
> can't yet be built against the new gcc, since the package itself won't |
27 |
> build with new gcc, and cmake won't run to let the package build with the |
28 |
> old gcc. |
29 |
|
30 |
Yeah I've run into situations like this many times. I fear it will only get |
31 |
worse as GCC seems to gather more and more external dependencies every |
32 |
release. If some future mandatory dependency links to libstdc++ it would |
33 |
seem to me that building that package with a newer GCC could make it very |
34 |
difficult to switch back. We already have this situation with the graphite |
35 |
libs (ppl/cloog-ppl), but fortunately it only breaks the graphite options, |
36 |
not the entire compiler. |
37 |
|
38 |
Anyways, we're getting off topic here. |
39 |
|
40 |
-- |
41 |
fonts, gcc-porting, it makes no sense how it makes no sense |
42 |
toolchain, wxwidgets but i'll take it free anytime |
43 |
@ gentoo.org EFFD 380E 047A 4B51 D2BD C64F 8AA8 8346 F9A4 0662 |