Windows 7 build problem might be fixed, please test

[Ehsan Akhgari]

Dear hackers,

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!
--
Ehsan
<http://ehsanakhgari.org/>

[Honza Bambas]

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.

-hb-

> _______________________________________________
> dev-platform mailing list
> dev-pl...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
>
>

[Bob Clary]

On 1/19/12 11:48 AM, Honza Bambas wrote:
> 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.

[Marco Bonardo]

On 19/01/2012 20:09, Ehsan Akhgari wrote:
> Dear hackers,
>
> 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.

-m

[Chris Pearce]

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.


Chris P.

[Marco Bonardo]

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

[Ehsan Akhgari]

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.

--
Ehsan
<http://ehsanakhgari.org/>

[Justin Dolske]

On 1/19/12 11:09 AM, Ehsan Akhgari wrote:
> Dear hackers,
>
> 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!

:-)

Justin

[Neil]

Given how slow configure is anyway, I bet nobody would have noticed if
Ehsan hadn't announced it ;-)

--
Warning: May contain traces of nuts.

[Brian Smith]

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.

[Ryan VanderMeulen]

FYI, I've had no issues whatsoever since this patch landed. Definitely
working well for me.

[Benjamin Smedberg]

On 1/25/2012 8:08 PM, Brian Smith wrote:
>> 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.

--BDS

[Benjamin Smedberg]

On 1/30/2012 1:33 PM, Benjamin Smedberg wrote:
> 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".

--BDS