Fallout from bug 763651. 1. make -f client.mk from the toplevel with a mozconfig something like: ac_add_options --enable-debug ac_add_options --disable-optimize ac_add_options --enable-shared-js 2. Wait for it to finish, or break it after it builds the shell. 3. cd to obj/js/src. (If you make here now, it will do nothing and return happily.) 4. cut & paste the configure line from config.status, which should theoretically re-do the same configuration you just did. In my case (note that I didn't give my full mozconfig above, so there are some more options here): /home/sfink/src/MI-pending/js/src/configure --enable-debug --disable-optimize --enable-shared-js --enable-trace-jscalls --enable-sm-fail-on-warnings --enable-more-deterministic --enable-dtrace --enable-application=browser --enable-threadsafe --enable-ctypes --with-nspr-cflags=-I/home/sfink/src/MI-pending/obj/dist/include/nspr '--with-nspr-libs=-L/home/sfink/src/MI-pending/obj/dist/lib -lplds4 -lplc4 -lnspr4 -lpthread -ldl' --with-dist-dir=../../dist --prefix=/home/sfink/src/MI-pending/obj/dist --with-sync-build-files=/home/sfink/src/MI-pending --enable-jemalloc --cache-file=../.././config.cache --srcdir=/home/sfink/src/MI-pending/js/src 5. make Result: /home/sfink/src/MI-pending/js/src/jsutil.cpp:57: error: undefined reference to 'MOZ_Z_deflateInit_' /home/sfink/src/MI-pending/js/src/jsutil.cpp:62: error: undefined reference to 'MOZ_Z_deflate' /home/sfink/src/MI-pending/js/src/jsutil.cpp:63: error: undefined reference to 'MOZ_Z_deflateEnd' /home/sfink/src/MI-pending/js/src/jsutil.cpp:84: error: undefined reference to 'MOZ_Z_inflateInit_' /home/sfink/src/MI-pending/js/src/jsutil.cpp:89: error: undefined reference to 'MOZ_Z_inflate' /home/sfink/src/MI-pending/js/src/jsutil.cpp:91: error: undefined reference to 'MOZ_Z_inflateEnd'
Assignee: general → nobody
Too many things come from the environment when running configure for js/src when doing a full build (as opposed to a standalone js build) for that to work. You're failing with MOZ_Z_* functions now, but this previously led to subtle differences in the past. I'm tempted to say you're not supposed to do that. That being said, I'm in the middle of replacing config.status with something else, it could be accommodated to keep these inherited environment variables around.
I get a similar problem building thunderbird on ubuntu (with ac_add_options --enable-incomplete-external-linkage) /usr/bin/ld: libimport.so: hidden symbol `MOZ_Z_inflate' isn't defined /usr/bin/ld: final link failed: Bad value collect2: ld returned 1 exit status make: *** [libimport.so] Error 1 make: Leaving directory `/opt/moz-objdir/mail/mailnews/import/build' make: *** [libs] Error 2 make: Leaving directory `/opt/moz-objdir/mail/mailnews/import' make: *** [libs] Error 2 make: Leaving directory `/opt/moz-objdir/mail/mailnews' make: *** [libs_tier_app] Error 2 make: Leaving directory `/opt/moz-objdir/mail' make: *** [tier_app] Error 2 make: Leaving directory `/opt/moz-objdir/mail' make: *** [default] Error 2 make: Leaving directory `/opt/moz-objdir/mail' make: *** [build] Error 2 make: Leaving directory `/opt/comm-central/src'
(In reply to Mike Hommey [:glandium] from comment #1) > Too many things come from the environment when running configure for js/src > when doing a full build (as opposed to a standalone js build) for that to > work. You're failing with MOZ_Z_* functions now, but this previously led to > subtle differences in the past. I'm tempted to say you're not supposed to do > that. Upon rereading, I'm not sure I follow. What is the bad thing? Running js/src/configure directly, then doing a full browser build? That's unfortunate; I didn't know there was anything transmitted. But that's not what I'm complaining about here. I want to do: 1. toplevel make -f client.mk 2. manual configure in js/src (using the options listed in config.status) 3. shell-only build Is this expected to work? It always has for me in the past. This now breaks. In fact, I'm not even sure if #2 is necessary for it to break, which would really suck because that would prevent using --enable-shared-js. > That being said, I'm in the middle of replacing config.status with something > else, it could be accommodated to keep these inherited environment variables > around. Ok, cool. I tracked down what is causing this particular failure. The problem is that the toplevel make export creates an obj/dist/include/zlib.h that ends up #defining all of the zlib function names to MOZ_Z_* variants. Those symbols are provided in libxul.so. This works fine as long as you're linking with libxul.so, but when doing a shell-only build, this will spew out the undefined symbols. The quick fix is to delete obj/dist/include/zlib.h. That'll end up using the system zlib. Passing --enable-system-zlib to js/src/configure won't help, because it doesn't do anything with that option. The toplevel configure does. Maybe that means if I use it at the toplevel, then it won't drop in the interfering zlib.h? That would be a decent workaround, but there really should be a warning or something somewhere within js/src for this.
You need to log in before you can comment on or make changes to this bug.