[Interest] I am trying to compile Qt 4.8 with VS2010
sascha-ml at babbelbox.org
Thu Feb 7 10:49:23 CET 2013
Am Donnerstag, 7. Februar 2013, 08:45:57 schrieb Till Oliver Knoll:
> Am 07.02.2013 um 02:59 schrieb Scott Aron Bloom <scott.bloom at onshorecs.com>:
> > Just a suggestion...
> > If you use a "Project" directory, for source and building, add that
> > directory to your virus system as a white listed directory, ie don't
> > check it.
> Guido already stated that he's not using any virus scanner ;)
Yes, but it's in general a good advice to not let virus scanners interfer with
your "work" - including all consequences of that: Don't extract anything
obtained form internet into your source directories - at least not directly.
However, I know at least of 2 virus scanners who sometimes accidently conclude
that some temporary file generated during the compilation of Qt using Visual
Studio is a virus. Resulting in removal of the file and build process
stopping, which is a similar problem as with the resource file update-thing.
> My second guess would have been "network drive" (Samba, network delay,
> wrong/cached permissions, other oddities...) but he mentioned the C:\
> drive, so I assume that means local...
Indeed, unlikely on C:\
> Is the entire compilation process "multithreaded"? Could it be that some VS
> 2010 process is trying to access that DLL at the same time like some other
> VS process (which might then be a bug in VS itself, maybe triggered by
> "unusual generated Makefiles")? Is it possible to force "single process
> compilation/linking" in this case?
The whole nmake-process (which he said he's using) is not threaded at all.
That's in fact why jom exists.
> What Windows version was that again? Is it possible that some "search index"
> is being updated at the very moment that DLL is to be generated?
Possibile - but i've personally never seen that before.
Another piece of software that might be interested in a just-now-built
executable might be VS's pdb-server, which is a background server process for
accessing debug-symbols that is fed in background during compilation and used
during debugging sessions.
> What about trying to compile Qt onto some externally attached drive? Maybe
> your hard disk really has bad blocks which are just being marked as such
> the very moment you try to write them (any other data lost or corrupted
> recently? :-0)? (Doesn't that S.M.A.R.T. thing do that? Or was that just
> with "USB sticks"?)
Yes, it's the S.M.A.R.T. thing that does this - and it can be easily looked up
with a smart-monitoring tool. Bad-Sector relocation also applies to
"conventional" magnetic hard discs (They also have some fail over capacity).
OTOH nowadays, it is more likely that such happens on flash drives like USB
sticks, SD-Cards and SSD-type hard disc drives.
Actually, I've seen a few SSDs die, but this process usually shows "more
> And finally: did you try to tilt and maybe slightly shake your harddisk,
> such that the bits fall into the right place again?
Isn't this recommended against bit-rotting only?
> Maybe you have to adjust its orientation towards Redmond, too (No
> responsibility taken ;))
Unless you share the distance to equator with Redmond, in which case earth-
magnetism may interfere with such alignment :-)
> [From: "The Developer's Handbook About Esotheric Bugs You Wouldn't Believe
> They Exist (And Some Really Don't)" - Buggy Bookstore Press, ISBN 42]
More information about the Interest