| 1 |
Duncan <1i5t5.duncan@×××.net> posted pan.2009.01.28.14.30.10@×××.net, |
| 2 |
excerpted below, on Wed, 28 Jan 2009 14:30:10 +0000: |
| 3 |
|
| 4 |
> Thanks. BTW, gcc-4.3.3 is out now. I've upgraded but not tried it yet, |
| 5 |
> tho I will be trying it quite a bit shortly, merging KDE 4.2. |
| 6 |
|
| 7 |
FWIW, if you merged /any/ gcc (stable or unstable) early today (28th) and |
| 8 |
going back an unknown but reasonably limited time), you likely merged |
| 9 |
while toolchain.eclass has a bug that caused some of gcc's *.la files to |
| 10 |
have an incorrect path. There were in fact several other |
| 11 |
toolchain.eclass changes today (I checked the logs while working the |
| 12 |
above bug), so several other bugs may have occurred and been fixed as |
| 13 |
well. |
| 14 |
|
| 15 |
AFAIK, the bugs are fixed now. I know the one I was struck with is fixed. |
| 16 |
So anyone who has merged a gcc over the last week (say), may wish to |
| 17 |
remerge it, just to be sure. Either that or simply keep this in mind and |
| 18 |
if you see errors involving libgomp.la, /then/ remerge gcc. That's the |
| 19 |
bug that hit me. |
| 20 |
|
| 21 |
Again, this bug was NOT with any particular gcc version or its ebuild, |
| 22 |
but with an eclass (toolchain.eclass) all the gcc ebuilds use. Thus, it |
| 23 |
will have affected... probably any gcc merged while the bug was active. |
| 24 |
It will have certainly affected any with libgomp.la, so at least the |
| 25 |
gcc:4.2 and gcc:4.3 slots I have merged here, according to equery b |
| 26 |
libgomp.la. Doing a sync and remerging the gcc in question should fix |
| 27 |
the issue, as the eclass is now fixed. |
| 28 |
|
| 29 |
-- |
| 30 |
Duncan - List replies preferred. No HTML msgs. |
| 31 |
"Every nonfree program has a lord, a master -- |
| 32 |
and if you use the program, he is your master." Richard Stallman |
Archives