933231 - don't |unset| variables after configuring NSPR

Status: RESOLVED FIXED

(Firefox Build System :: General, defect)

Comment 1

[Nathan Froyd [:froydnj]]

Attachment: don't |unset| variables after configuring NSPR

|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.

Comment 2

[Nathan Froyd [:froydnj]]

https://hg.mozilla.org/integration/mozilla-inbound/rev/82ceed608666

Comment 3

[Ed Morley [:emorley]]

Backed out on suspicion of asan link failures:
https://tbpl.mozilla.org/php/getParsedLog.php?id=29974465&tree=Mozilla-Inbound
https://tbpl.mozilla.org/php/getParsedLog.php?id=29974660&tree=Mozilla-Inbound

https://hg.mozilla.org/integration/mozilla-inbound/rev/4ef640375e5d

Comment 4

[Nathan Froyd [:froydnj]]

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)?

Comment 5

[Christian Holler (:decoder)]

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.

Comment 6

[Christian Holler (:decoder)]

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.

Comment 7

[Christian Holler (:decoder)]

m_kato fixed ICU such that it uses our CFLAGS/CXXFLAGS in bug 912371. You should be able to proceed now with this bug :)

Comment 8

[Nathan Froyd [:froydnj]]

Green try builds: https://tbpl.mozilla.org/?tree=Try&rev=416e0c49b8b1
Relanded: https://hg.mozilla.org/integration/mozilla-inbound/rev/838f865fa1c7

Comment 9

[Carsten Book [:Tomcat]]

https://hg.mozilla.org/mozilla-central/rev/838f865fa1c7

Comment 10

[Eric Rescorla (:ekr)]

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

Comment 11

[Ryan VanderMeulen [:RyanVM]]

Backed out for the bustage in comment 10.
https://hg.mozilla.org/integration/mozilla-inbound/rev/178b13eade34

Comment 12

[Nathan Froyd [:froydnj]]

Previously-green try run: https://tbpl.mozilla.org/?tree=Try&rev=416e0c49b8b1

I do not understand what is the matter here...

Comment 13

[Nathan Froyd [:froydnj]]

(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?

Comment 14

[Eric Rescorla (: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

Comment 15

[Justin Dolske [:Dolske]]

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
---

Comment 16

[Justin Dolske [:Dolske]]

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

Comment 17

[Mike Hommey [:glandium]]

FYI, this patch broke mac l10n builds even more than they already were broken. (bug 946605)

Comment 18

[Michael Shal [:mshal]]

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?

Comment 19

[Justin Dolske [:Dolske]]

I just successfully completed a clobber build with a current m-c and this patch.

Comment 20

[Michael Shal [:mshal]]

froydnj, any reason not to try to re-land this patch given #c19?

Comment 21

[Nathan Froyd [:froydnj]]

(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.

Comment 22

[Nathan Froyd [:froydnj]]

Relanded: https://hg.mozilla.org/integration/mozilla-inbound/rev/42207a3dae80

Comment 23

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/mozilla-central/rev/42207a3dae80