| 1 |
On Mon, Dec 26, 2011 at 07:23:27PM +0100, Alex Schuster wrote |
| 2 |
> Hi there! |
| 3 |
> |
| 4 |
> I'm currently upgrading my little sister's PC from an x86 Sempron to an |
| 5 |
> x86_64 AMDS A6 processor. So Gentoo is being installed from scratch. |
| 6 |
> |
| 7 |
> But some packages fail to build. I filed a bug [1] for |
| 8 |
> media-libs/libggi-2.2.2, but a similar problem is happening for |
| 9 |
> pygtksourceview now, and I do not find a simple workaround. |
| 10 |
> |
| 11 |
> The problem is that in the libtool linking phase the arguments "/usr/bin |
| 12 |
> /usr/sbin /bin /sbin" are given along the libraries and library paths. I |
| 13 |
> have no idea why this happens, and how to solve this. Something must be |
| 14 |
> wrong on my system. But what? For libggi, emerging with USE=-aalib sort |
| 15 |
> of solved this. But I have no idea what to do about pygtksourceview. As |
| 16 |
> all gthe KDE stuff seems to depend on this, I cannot continue |
| 17 |
|
| 18 |
I notice that you have 'MAKEOPTS="-j4"'. You wouldn't believe how |
| 19 |
many problems you can solve by changing to 'MAKEOPTS="-j1"'. Yes, the |
| 20 |
build process may take a bit longer, but the final executable runs just |
| 21 |
as fast. Change to 'MAKEOPTS="-j1"' and see what happens. |
| 22 |
|
| 23 |
The concept of parallel jobs is nice in theory, and you can *USUALLY* |
| 24 |
get away with it. The problem is that if a job tries to use an |
| 25 |
intermediate file before it's fully created, or if the "destructor" |
| 26 |
(file deletion) does it's thing before the scratch file has been used, |
| 27 |
things get very fouled up. My attitude is that the first time you spend |
| 28 |
hours trying to trace down a non-replicatable bug, you will lose more |
| 29 |
time than you "save" by speeding up builds with 'MAKEOPTS="-j4"'. |
| 30 |
|
| 31 |
-- |
| 32 |
Walter Dnes <waltdnes@××××××××.org> |
Archives