If you have built mozilla on Windows 7, you have no doubt faced your
configure script failing with an error message about being unable to remove
conftest.exe. This is bug 545015. Yesterday I landed a fix which should
hopefully make the situation better. If you build a clone of
mozilla-central which has this revision <
https://hg.mozilla.org/mozilla-central/rev/0fcee05b6e0a>, please comment on
the bug and let us know. Given the intermittent nature of the bug, I need
your help to be certain that my hacky patch has indeed fixed the problem.
Thanks for this! My experience with this bug was that it appeared ones (whenever I started a build and switched to other window) and on a second try it never happened again.
I do builds regularly every day and if that won't happen again, I'll comment on the bug.
> If you have built mozilla on Windows 7, you have no doubt faced your
> configure script failing with an error message about being unable to remove
> conftest.exe. This is bug 545015. Yesterday I landed a fix which should
> hopefully make the situation better. If you build a clone of
> mozilla-central which has this revision<
> https://hg.mozilla.org/mozilla-central/rev/0fcee05b6e0a>, please comment on
> the bug and let us know. Given the intermittent nature of the bug, I need
> your help to be certain that my hacky patch has indeed fixed the problem.
> Thanks for this! My experience with this bug was that it appeared ones
> (whenever I started a build and switched to other window) and on a
> second try it never happened again.
> I do builds regularly every day and if that won't happen again, I'll
> comment on the bug.
I've hit this pretty regularly in the past building on Windows 7 32bit but not doing 32 bit builds on Windows 7 64 bit for some reason. I thought it was just me. I've kicked off a sequence of checkout depends build cycles on Windows 7 32bit and so far hit it on the first checkout, but not on the second. I'll let you know how the full set of builds do.
> If you have built mozilla on Windows 7, you have no doubt faced your
> configure script failing with an error message about being unable to remove
> conftest.exe. This is bug 545015. Yesterday I landed a fix which should
> hopefully make the situation better.
Thanks, many times I've started a build and then noticed 10 or 15 minutes later that it never started, so I really have hopes on this fix.
Another similar error I hit frequently is the "Compiler cannot create executables" one, though just relaunching everything works correctly.
> On 20/01/2012 9:51 a.m., Marco Bonardo wrote:
>> Another similar error I hit frequently is the "Compiler cannot create
>> executables" one, though just relaunching everything works correctly.
> Usually I hit this when Firefox has not shut down properly. Typically
> killing the Firefox process in TaskManager makes the build work again.
I'm pretty sure that when it happened I always just retriggered the build, and it immediately worked. I never had to kill anything.
When I forgot to close it I usually just get a linking error in libxul.
-m
On Thu, Jan 19, 2012 at 4:09 PM, Marco Bonardo <ma...@supereva.it> wrote:
> On 19/01/2012 21:59, Chris Pearce wrote:
>> On 20/01/2012 9:51 a.m., Marco Bonardo wrote:
>>> Another similar error I hit frequently is the "Compiler cannot create
>>> executables" one, though just relaunching everything works correctly.
>> Usually I hit this when Firefox has not shut down properly. Typically
>> killing the Firefox process in TaskManager makes the build work again.
> I'm pretty sure that when it happened I always just retriggered the build,
> and it immediately worked. I never had to kill anything.
> When I forgot to close it I usually just get a linking error in libxul.
I believe that is the same error that I am trying to fix. What happens is
that rm first tries to delete an executable, and it fails. Then we try to
compile another executable with the same target path, which fails because
the exe cannot be written to, which triggers the "Compiler cannot create
executables" error.
> If you have built mozilla on Windows 7, you have no doubt faced your
> configure script failing with an error message about being unable to remove
> conftest.exe. This is bug 545015. Yesterday I landed a fix which should
> hopefully make the situation better. If you build a clone of
> mozilla-central which has this revision<
> https://hg.mozilla.org/mozilla-central/rev/0fcee05b6e0a>
sleep(1)? Do you not understand how much this will slow down builds?!!1!
>> If you have built mozilla on Windows 7, you have no doubt faced your >> configure script failing with an error message about being unable to >> remove conftest.exe. This is bug 545015. Yesterday I landed a fix >> which should hopefully make the situation better. If you build a >> clone of mozilla-central which has this >> revision<https://hg.mozilla.org/mozilla-central/rev/0fcee05b6e0a>
> sleep(1)? Do you not understand how much this will slow down builds?!!1!
Given how slow configure is anyway, I bet nobody would have noticed if Ehsan hadn't announced it ;-)
L. David Baron wrote:
> On Wednesday 2012-01-25 16:36 -0800, Brian Smith wrote:
> > Since configure is incredibly slow on Windows, and kind of
> > bugging, why not just stop configuring so much for Windows builds?
> > On Windows, we know you're building with a MSVC and I think it is
> I'd rather see us use autoconf *more* on Windows.
> Right now, we use autoconf a good bit for compiler feature tests.
> Many of those tests are actually skipped on Windows; we have to
> hard-code the results (or else Windows ends up using the slow path,
> or not-as-good path, or whatever).
I think it would be better to run configure once every 5 years* when we update the standard compiler version on Windows, and check the result into mozilla-central, than run it once every build, considering how slow configure is on Windows. We'd get better build performance and more consistent builds across developers' machines.
> For example, nsCOMPtr logging, used for leak debugging, isn't
> supported on Windows because MSVC doesn't support
> dynamic_cast<void*>(). Or maybe newer versions do support it -- I
> don't know. If we ran our autoconf feature tests on Windows, maybe
> this useful leak debugging tool would magically get enabled on
> Windows.
Build configuration should not be magic, but reproducible.
> (I probably get asked about why it doesn't work on Windows
> a few times a year, and I don't remember when the last time I talked
> somebody in to manually testing a current MSVC version was.)
Please send me a link or bug # to a more detailed description of the problem and how to test it, and I will test it on MSVC2010.
> I don't see why this follows. If you have to clobber your objdir,
> it's a build system bug. Just build with client.mk and it will
> rerun configure only when needed, which in turn will invalidate
> mozilla-config.h only when needed.
I have had bad luck with this in the past, to the point where I pretty much automatically "rm -Rf ff-dbg" after "hg pull -u" nowadays. I will try to be less pessimistic about it and file a bug about what doesn't work, if anything.
- Brian
* This is just a joke about leaping from MSVC 2005 to MSVC 2010. Hopefully, we will upgrade compilers more frequently going forward.
> If you have built mozilla on Windows 7, you have no doubt faced your
> configure script failing with an error message about being unable to remove
> conftest.exe. This is bug 545015. Yesterday I landed a fix which should
> hopefully make the situation better. If you build a clone of
> mozilla-central which has this revision<
> https://hg.mozilla.org/mozilla-central/rev/0fcee05b6e0a>, please comment on
> the bug and let us know. Given the intermittent nature of the bug, I need
> your help to be certain that my hacky patch has indeed fixed the problem.
Discussion subject changed to "Why do we even use autoconf on Windows? (was Re: Windows 7 build problem might be fixed, please test)" by Benjamin Smedberg
>> I don't see why this follows. If you have to clobber your objdir,
>> it's a build system bug. Just build with client.mk and it will
>> rerun configure only when needed, which in turn will invalidate
>> mozilla-config.h only when needed.
> I have had bad luck with this in the past, to the point where I pretty much automatically "rm -Rf ff-dbg" after "hg pull -u" nowadays. I will try to be less pessimistic about it and file a bug about what doesn't work, if anything.
configure does a lot of stuff for us. It's not super-fast, but typically people don't run it very often (once a pull or less) and it's not in the critical-path code/debug/rebuild cycle, so its speed has not been on the top of our list of things to optimize. I think that the complexity and confusion cost of removing configure would be worth the time it would take to replicate only the bits of it that we actually use.
> I think that the complexity and confusion cost of removing configure > would be worth the time it would take to replicate only the bits of it > that we actually use.
And I of course meant "would *not* be worth the time".
