776126 - link failure on zlib

Status: NEW

(Firefox Build System :: General, defect)

Description

[Steve Fink [:sfink] [:s:]]

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'

Comment 1

[Mike Hommey [:glandium]]

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.

Comment 3

[Magnus Melin [:mkmelin]]

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[7]: *** [libimport.so] Error 1
make[7]: Leaving directory `/opt/moz-objdir/mail/mailnews/import/build'
make[6]: *** [libs] Error 2
make[6]: Leaving directory `/opt/moz-objdir/mail/mailnews/import'
make[5]: *** [libs] Error 2
make[5]: Leaving directory `/opt/moz-objdir/mail/mailnews'
make[4]: *** [libs_tier_app] Error 2
make[4]: Leaving directory `/opt/moz-objdir/mail'
make[3]: *** [tier_app] Error 2
make[3]: Leaving directory `/opt/moz-objdir/mail'
make[2]: *** [default] Error 2
make[2]: Leaving directory `/opt/moz-objdir/mail'
make[1]: *** [build] Error 2
make[1]: Leaving directory `/opt/comm-central/src'

Comment 4

[Steve Fink [:sfink] [:s:]]

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

Comment 5

[wraitii]

I confirm this happens in SM60, and I guess up to HEAD^ but I can report on that later.

Interestingly, we encountered a variant of this issue with ICU on linux systems and the spidermonkey packages provided by distros. See https://trac.wildfiregames.com/ticket/5868

Basically Spidermonkey includes ICU headers (depending on the build settings), which breaks code that looks for system ICU. On linux, this is somewhat easily remedied by using the dirafter option of GCC and clang.

The zlib issue is still fixed by deleting the files in 0 A.D., though we could probably just link spidermonkey via the INCLUDE env variable, which apparently comes later.