Closed Bug 933231 Opened 6 years ago Closed 6 years ago

don't |unset| variables after configuring NSPR

Categories

(Firefox Build System :: General, defect)

defect
Not set

Tracking

(Not tracked)

RESOLVED FIXED
mozilla30

People

(Reporter: froydnj, Assigned: froydnj)

References

Details

Attachments

(1 file)

No description provided.
|unset|'ing these things causes them to not be exported to future configure's
(JS's, especially, in this context).  It's also completely unlike what we do
with other _SAVE-style variables elsewhere in configure.  Reassignment should
be enough.
Attachment #825280 - Flags: review?(ted)
Blocks: 921040
Attachment #825280 - Flags: review?(ted) → review+
Assignee: nobody → nfroyd
Turns out that this does break things for asan only.  Christian, do you know what sort of hacks ASan does to CFLAGS/CPPFLAGS/LDFLAGS to make things work correctly?  Does it not pass ASan versions into third-party packages (like ICU)?
Flags: needinfo?(choller)
I'm traveling right now and will look into this in more detail by Monday. But we *should* pass ASan flags to each and every library we build. I haven't checked explicitly if ICU is receiving them yet. Before ICU, I think all libraries we built (including NSPR and NSS) got the flags properly, but I had to make a small patch for NSS to get them.

Keeping the needinfo.
Depends on: 934715
The actual problem here is that ICU does not respect our CFLAGS/CXXFLAGS but with the patch in here, it will readily take our LDFLAGS. This breaks at least ASan builds but I would consider this a bug in general. I filed bug 934715 to have ICU accept our CFLAGS and CXXFLAGS properly.
Flags: needinfo?(choller)
m_kato fixed ICU such that it uses our CFLAGS/CXXFLAGS in bug 912371. You should be able to proceed now with this bug :)
https://hg.mozilla.org/mozilla-central/rev/838f865fa1c7
Status: NEW → RESOLVED
Closed: 6 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla28
This causes compile failures when combined with clobber on my Mac (Mountain Lion)

Apple LLVM version 4.2 (clang-425.0.28) (based on LLVM 3.2svn)
Target: x86_64-apple-darwin12.5.0
Thread model: posix


See:

configure:27410: checking for posix_fallocate
configure:27420: /opt/local/bin/ccache /usr/bin/clang -o conftest -Qunused-arguments -Wall -Wpointer-arith -Wdeclaration-after-statement -Werror=return-type -Wtype-limits -Wempty-body -Wsign-compare -Wno-unused -std=gnu99 -fno-strict-aliasing -fno-math-errno -pthread -DNO_X11 -pipe -Qunused-arguments    -framework Cocoa -lobjc conftest.c  1>&5
configure:27416:1: warning: implicit declaration of function 'posix_fallocate' is invalid in C99 [-Wimplicit-function-declaration]
posix_fallocate(0, 0, 0);
^
1 warning generated.
Undefined symbols for architecture x86_64:
  "_posix_fallocate", referenced from:
      _main in conftest-IF8Xzx.o
ld: symbol(s) not found for architecture x86_64
clang: error: linker command failed with exit code 1 (use -v to see invocation)
configure: failed program was:
#line 27412 "configure"
#include "confdefs.h"
#define _XOPEN_SOURCE 600
  #include <fcntl.h>
int main() {
posix_fallocate(0, 0, 0);
; return 0; }
configure: error: /Users/ekr/dev/gecko/gecko-dev/js/src/configure failed for js/src
Backed out for the bustage in comment 10.
https://hg.mozilla.org/integration/mozilla-inbound/rev/178b13eade34
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Target Milestone: mozilla28 → ---
Previously-green try run: https://tbpl.mozilla.org/?tree=Try&rev=416e0c49b8b1

I do not understand what is the matter here...
(In reply to Eric Rescorla (:ekr) from comment #10)
> This causes compile failures when combined with clobber on my Mac (Mountain
> Lion)
> 
> Apple LLVM version 4.2 (clang-425.0.28) (based on LLVM 3.2svn)
> Target: x86_64-apple-darwin12.5.0
> Thread model: posix
> 
> 
> See:
> 
> configure:27410: checking for posix_fallocate
> configure:27420: /opt/local/bin/ccache /usr/bin/clang -o conftest
> -Qunused-arguments -Wall -Wpointer-arith -Wdeclaration-after-statement
> -Werror=return-type -Wtype-limits -Wempty-body -Wsign-compare -Wno-unused
> -std=gnu99 -fno-strict-aliasing -fno-math-errno -pthread -DNO_X11 -pipe
> -Qunused-arguments    -framework Cocoa -lobjc conftest.c  1>&5
> configure:27416:1: warning: implicit declaration of function
> 'posix_fallocate' is invalid in C99 [-Wimplicit-function-declaration]
> posix_fallocate(0, 0, 0);
> ^
> 1 warning generated.
> Undefined symbols for architecture x86_64:
>   "_posix_fallocate", referenced from:
>       _main in conftest-IF8Xzx.o
> ld: symbol(s) not found for architecture x86_64
> clang: error: linker command failed with exit code 1 (use -v to see
> invocation)
> configure: failed program was:
> #line 27412 "configure"
> #include "confdefs.h"
> #define _XOPEN_SOURCE 600
>   #include <fcntl.h>
> int main() {
> posix_fallocate(0, 0, 0);
> ; return 0; }
> configure: error: /Users/ekr/dev/gecko/gecko-dev/js/src/configure failed for
> js/src

What does a successful configure run for this say?  And what is your mozconfig?
Flags: needinfo?(ekr)
 0:07.51 checking for posix_fallocate... no

1 warning generated.
Undefined symbols for architecture x86_64:
  "_posix_fallocate", referenced from:
      _main in conftest-ZE0ohh.o
ld: symbol(s) not found for architecture x86_64
clang: error: linker command failed with exit code 1 (use -v to see invocation)
configure: failed program was:
#line 27404 "configure"
#include "confdefs.h"
#define _XOPEN_SOURCE 600
  #include <fcntl.h>
int main() {
posix_fallocate(0, 0, 0);
; return 0; }


.mozconfig:

mk_add_options MOZ_MAKE_FLAGS="-j4"
ac_add_options --enable-debug 
ac_add_options --disable-optimize 
ac_add_options --enable-tests
ac_add_options --disable-crashreporter
ac_add_options --enable-debug-symbols
ac_add_options --with-ccache=/opt/local/bin/ccache
ac_add_options --enable-webrtc-tests
export MOZ_WEBRTC_TESTS=1
export MOZ_WEBRTC_LEAKING_TESTS=1
# make valgrind work
ac_add_options --disable-jemalloc
#ac_add_options --enable-valgrind
#ac_add_options --enable-gtest
#export MOZ_ENABLE_GTEST=1
mk_add_options AUTOCLOBBER=1
export NO_XPCSHELL_MANIFEST_CHECK=1
#ac_add_options --enable-warnings-as-errors
Flags: needinfo?(ekr)
FWIW, my (clobber) build crapped out here:

configure: error: in `/Users/dolske/build/mozilla-central/obj/js/src/ctypes/libffi':

and backing this patch out has fixed it.

Nothing terribly interesting in my mozconfig:

---
mk_add_options MOZ_OBJDIR=@TOPSRCDIR@/obj
mk_add_options AUTOCLOBBER=1
mk_add_options MOZ_MAKE_FLAGS="-s -j12"

ac_add_options --enable-official-branding
export MOZILLA_OFFICIAL=1
---
Oh, and earlier from IRC:

[16:37] <bhackett> gavin: I'm getting errors like this when building:
[16:37] <bhackett>  0:32.34 configure: error: in `/Users/bhackett/mozilla-inbound4/ff-dbg/js/src/ctypes/libffi': 
[16:37] <bhackett>  0:32.34 configure: error: C compiler cannot create executables 
[16:37] <bhackett> this has worked fine for me before
[16:38] <bhackett> I have no idea what's changed and it's breaking for me in a newly cloned tree too
...
[16:52] <bhackett> gavin: I just reinstalled my OS a few weeks ago
[16:53] <gavin> that could result in xcode getting messed up
[16:53] <bhackett> I did a fresh install of xcode on top of that
[16:53] <bhackett> gavin: I hacked js/src/configure.in to remove the -Wtype-limits stuff, and that seems to have gotten it to proceed
FYI, this patch broke mac l10n builds even more than they already were broken. (bug 946605)
Can :Dolske or :ekr check if applying this patch on a recent m-c tree still fails? I tried it on my Mac (10.8.4) with the mozconfigs from #c14 (except without ccache) and #c15, but they both succeeded. If it fails, maybe one of you could help me reproduce the failure locally?
Flags: needinfo?(ekr)
Flags: needinfo?(dolske)
I just successfully completed a clobber build with a current m-c and this patch.
Flags: needinfo?(ekr)
Flags: needinfo?(dolske)
froydnj, any reason not to try to re-land this patch given #c19?
Flags: needinfo?(nfroyd)
(In reply to Michael Shal [:mshal] from comment #20)
> froydnj, any reason not to try to re-land this patch given #c19?

Don't think so.  I'll run it through try to make sure we haven't broken anything in the interim and re-land if everything checks out.
Flags: needinfo?(nfroyd)
https://hg.mozilla.org/mozilla-central/rev/42207a3dae80
Status: REOPENED → RESOLVED
Closed: 6 years ago6 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla30
Product: Core → Firefox Build System
You need to log in before you can comment on or make changes to this bug.