Closed Bug 1283678 Opened 5 years ago Closed 5 years ago
MSVC VS2015u2: memory\jemalloc\src> configure: error: Cannot build without ffsl(3) or __builtin
Bisect shows this error starts at: https://hg.mozilla.org/mozilla-central/rev/7c3a439aee1c9e5a35fe96d9864c0f741ccb6207
Review commit: https://reviewboard.mozilla.org/r/61710/diff/#index_header See other reviews: https://reviewboard.mozilla.org/r/61710/
Some more information on the problem, like a log from configure, would be really helpful. Your patch stops exporting CFLAGS to the libffi subconfigure in the cross-compile case, which isn't going to fly. It's extremely odd this patch breaks anything, because: - you're not using clang-cl - you're not compiling for arm - you're not cross-compiling (I assume?) and I think other people have compiled successfully with 2015u2 and beyond....
(In reply to Nathan Froyd [:froydnj] from comment #2) > Some more information on the problem, like a log from configure, would be > really helpful. Your patch stops exporting CFLAGS to the libffi > subconfigure in the cross-compile case, which isn't going to fly. > > It's extremely odd this patch breaks anything, because: > > - you're not using clang-cl > - you're not compiling for arm > - you're not cross-compiling (I assume?) > > and I think other people have compiled successfully with 2015u2 and > beyond.... automation builds successfully with 2015u2...
Can you provide the config.log from jemalloc's configure? Did you change anything in your MSVC installation lately?
Comment on attachment 8766996 [details] Bug 1283678 - Reset CFLAGS ASAP. - Review request updated; see interdiff: https://reviewboard.mozilla.org/r/61710/diff/1-2/
The problem here is that we: 1. Saved CFLAGS; 2. Modified CFLAGS in certain circumstances; 3. Exported CFLAGS if we were cross-compiling; 4. [MSVC only] Nulled out CFLAGS 5. Ran the subconfigure; 6. Restored CFLAGS from step 1. Notice that on MSVC, CFLAGS now reflects the CFLAGS we had before running the libffi subconfigure, rather than the cleared CFLAGS we had before the -no-integrated-as patch landed. It's not clear to me why this is a problem for jgilbert only and not for our automation (which also runs MSVC 2015u2). We obviously have some sort of problem in the way our exporting of variables works across .m4 files and the like. Nevertheless, this fix at least gets us back to a state where we are no worse than when the -no-integrated-as patch landed. Passing variables via configure args is cleaner than passing them in the environment in any event. jgilbert confirms that the patch works for him; I can confirm the patch does the right thing for a clang/android build. It ought to work for our normal gcc/android builds as well.
...and of course this breaks the world on Android builds with inscrutable errors like: https://treeherder.mozilla.org/logviewer.html#?job_id=23260212&repo=try#L1819 I'll try to have a look with a local build next week.
Works better if you pass in the correct variables. :)
Attachment #8767377 - Flags: review?(mh+mozilla)
Attachment #8767377 - Flags: review?(mh+mozilla) → review+
Pushed by firstname.lastname@example.org: https://hg.mozilla.org/integration/mozilla-inbound/rev/879d2cba0b03 pass variables to libffi's subconfigure directly rather than exporting them; r=glandium
I'm getting this again.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
I filed bug 1304869 to track this new instance.
Status: REOPENED → RESOLVED
Closed: 5 years ago → 5 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.