Summary: | ktorrent-2.0 fails to compile due to possible parallel-unfriendly makefile | ||
---|---|---|---|
Product: | [Applications] ktorrent | Reporter: | Deathwing00 <deathwing00> |
Component: | general | Assignee: | Joris Guisson <joris.guisson> |
Status: | RESOLVED WORKSFORME | ||
Severity: | normal | ||
Priority: | NOR | ||
Version: | unspecified | ||
Target Milestone: | --- | ||
Platform: | Gentoo Packages | ||
OS: | Linux | ||
Latest Commit: | Version Fixed In: |
Description
Deathwing00
2006-08-15 02:21:36 UTC
The header file ipblockingpref.h is generated from ipblockingpref.ui. Normally automake should handle this so that make first generates the header and then proceeds to compile anything which includes this header. Is that the only place it fails ? We use .ui files all over the project, so if this were the only place, it would be very strange. I know that ipblockingpref.h is generated from ipblockingpref.ui at the beginning, but as I stated before we were unable to reproduce this bug. I personally still think that there is something wrong with the users system configuration, however a race condition might occur as well. I will see if I can reproduce it. Tried compiling with make -j5, problem does not happen. Maybe this is an obscure bug in make ? If you have a look at https://bugs.gentoo.org/show_bug.cgi?id=143799, you will see additional details. I am here using distcc and -j5 and -j4 and it works correctly. I have asked the user to post his information to this bug. Can't reproduce, so closed. Sorry for the long delay in getting back to you; I had a mailserver crash (hardware failed completely), and I've only just finished recovering old mail. For referenc, I've found the cause of the problem, but not a permanent solution. I have net-misc/ntp syncing my time; at the moment, my PC's clock is running fast (just enough to cause ntp to be occasionally stepping the time backwards), due to the hot weather. ntp's log shows that the failed compiles were occurring at a point when it was stepping the time regularly. Waiting for cooler weather, when the clock was staying within ntp's required 500 ppm stability was enough to fix the problem. I'm now looking in ntp's documentation for a way to force it to never step the clock, but only to slew the clock. Interesting, so NTP was causing this, can't you just decrease the NTP update interval, to prevent this backward stepping ? |