264407 - nsZipArchive.o doesn't link

Status: RESOLVED FIXED

(SeaMonkey :: Build Config, defect)

Description

[Ben Bucksch (:BenB)]

SuSE 9.1

../../../../dist/lib/libjar50_s.a(nsZipArchive.o)(.text+0x3f0): In function
`nsZipReadState::Init(nsZipItem*, _IO_FILE*)':
: undefined reference to `inflateInit2_'
../../../../dist/lib/libjar50_s.a(nsZipArchive.o)(.text+0x412): In function
`nsZipReadState::Init(nsZipItem*, _IO_FILE*)':
: undefined reference to `crc32'
../../../../dist/lib/libjar50_s.a(nsZipArchive.o)(.text+0x158e): In function
`nsZipArchiveStandalone::CopyItemToDisk(nsZipItem const*, _IO_FILE*, _IO_FILE*)':
: undefined reference to `crc32'
../../../../dist/lib/libjar50_s.a(nsZipArchive.o)(.text+0x162c): In function
`nsZipArchiveStandalone::CopyItemToDisk(nsZipItem const*, _IO_FILE*, _IO_FILE*)':
: undefined reference to `crc32'
../../../../dist/lib/libjar50_s.a(nsZipArchive.o)(.text+0x174a): In function
`nsZipArchiveStandalone::InflateItem(nsZipItem const*, _IO_FILE*, _IO_FILE*)':
: undefined reference to `inflateInit2_'
../../../../dist/lib/libjar50_s.a(nsZipArchive.o)(.text+0x17a6): In function
`nsZipArchiveStandalone::InflateItem(nsZipItem const*, _IO_FILE*, _IO_FILE*)':
: undefined reference to `crc32'
../../../../dist/lib/libjar50_s.a(nsZipArchive.o)(.text+0x18c8): In function
`nsZipArchiveStandalone::InflateItem(nsZipItem const*, _IO_FILE*, _IO_FILE*)':
: undefined reference to `inflate'
../../../../dist/lib/libjar50_s.a(nsZipArchive.o)(.text+0x18e9): In function
`nsZipArchiveStandalone::InflateItem(nsZipItem const*, _IO_FILE*, _IO_FILE*)':
: undefined reference to `crc32'
../../../../dist/lib/libjar50_s.a(nsZipArchive.o)(.text+0x19ab): In function
`nsZipArchiveStandalone::InflateItem(nsZipItem const*, _IO_FILE*, _IO_FILE*)':
: undefined reference to `inflateEnd'
../../../../dist/lib/libjar50_s.a(nsZipArchive.o)(.text+0x1ab3): In function
`nsZipArchiveStandalone::TestItem(nsZipItem const*, _IO_FILE*)':
: undefined reference to `inflateInit2_'
../../../../dist/lib/libjar50_s.a(nsZipArchive.o)(.text+0x1b0a): In function
`nsZipArchiveStandalone::TestItem(nsZipItem const*, _IO_FILE*)':
: undefined reference to `crc32'
../../../../dist/lib/libjar50_s.a(nsZipArchive.o)(.text+0x1d25): In function
`nsZipArchiveStandalone::TestItem(nsZipItem const*, _IO_FILE*)':
: undefined reference to `inflate'
../../../../dist/lib/libjar50_s.a(nsZipArchive.o)(.text+0x1d55): In function
`nsZipArchiveStandalone::TestItem(nsZipItem const*, _IO_FILE*)':
: undefined reference to `crc32'
../../../../dist/lib/libjar50_s.a(nsZipArchive.o)(.text+0x1d91): In function
`nsZipArchiveStandalone::TestItem(nsZipItem const*, _IO_FILE*)':
: undefined reference to `crc32'
../../../../dist/lib/libjar50_s.a(nsZipArchive.o)(.text+0x1e1c): In function
`nsZipArchiveStandalone::TestItem(nsZipItem const*, _IO_FILE*)':
: undefined reference to `inflateEnd'
collect2: ld returned 1 exit status
gmake[3]: *** [mozilla-installer-bin] Fehler 1
gmake[2]: *** [libs] Fehler 2
gmake[1]: *** [tier_50] Fehler 2
make: *** [default] Fehler 2

Comment 1

[cls]

Ben, you need to attach the build log to this.  At a glance, it looks like a
static build where mozilla-installer-bin isn't being passed -lz to get the zlib
symbols.  However, ZLIB_LIBS is set in that makefile.  More information is needed.

Comment 2

[Ben Bucksch (:BenB)]

Attachment: .mozconfig

Sure. This is the .mozconfig I used for this build (it's intended to compile
fast). I'll attach the |make| output in a few mins.

Comment 3

[Ben Bucksch (:BenB)]

Attachment: make output

With "build log", you meant the |make output|, right?

I had to cut in the middle, because it was more than the 300K that bugzilla now
allows.

Comment 4

[cls]

Yeah, I meant the make output.  It looks like the installer makefiles haven't
changed in ages and that the problem is that libjar50_s.a no longer has the
'standalone' zlib symbols included.  Can you do a 'make -C modules/libjar clean
all' and attach the output?

Comment 5

[Ben Bucksch (:BenB)]

Attachment: make -C modules/libjar clean all

(stderr at the end, it ended up on the console despite 2>&1 )

Comment 6

[cls]

Ok, the libjar build looks fine except that it didn't use the standalone zlib
headers to build.  Not sure why that would cause this problem though.

In modules/libjar/standalone/Makefile.in, try adding:
    -I$(DIST)/include/zlib
to LOCAL_INCLUDES and then rebuild libjar & xpinstall.

Comment 7

[Ben Bucksch (:BenB)]

That worked, it seems

> it didn't use the standalone zlib headers to build.
> Not sure why that would cause this problem though.

Could it be that smart-ass logic which overrides my --with-system-zlib when the
configure script thinks that it has a newer zlib (with less security holes) in
the Mozilla tree than on my system?

Comment 8

[Ben Bucksch (:BenB)]

> That worked, it seems

Yes, it did, I also did a depend make afterwards and it went through as well.

Comment 9

[cls]

(In reply to comment #7)
> That worked, it seems
> 
> > it didn't use the standalone zlib headers to build.
> > Not sure why that would cause this problem though.
> 
> Could it be that smart-ass logic which overrides my --with-system-zlib when the
> configure script thinks that it has a newer zlib (with less security holes) in
> the Mozilla tree than on my system?

Yes & no.  The standalone libjar is supposed to always use the 'standalone'
version of zlib regardless of the --with-system-zlib setting.  The idea being
that the installer (the only thing that uses standalone jar) will have no
external dependencies. 

In this case though, it looks like you hit a symbol mismatch when using the
wrong headers.  Still not sure how that happened since the tree has zlib 1.2.1
and they're C symbols so they shouldn't have different signatures.

Comment 10

[cls]

Attachment: Use standalone zlib headers when building standalone jar

Comment 11

[Ben Bucksch (:BenB)]

Just to make sure I understand it correctly:
- There is always a "standalone" version of libjar, i.e. one built from zlib
sources in the Mozilla tree and without external dependencies,  being built and
it is used *only* by the installer executable, not for opening jar: URLs in the
browser and not for installing XPIs in the browser either.
- The libjar used by the browser follows my configure flag (or not, because of
the bug described in comment 7)
- The bug here is that during building the standalone version, the system
headers were used.
- You change has no effect whatsoever on the libjar for the browser.

I just applied your patch (and unapplied the earlier change), rebuilt and it
works. Thanks!

Comment 12

[cls]

That is correct.  The patch has been checked in.

Comment 13

[Christian :Biesinger (don't email me, ping me on IRC)]

>Still not sure how that happened since the tree has zlib 1.2.1
>and they're C symbols so they shouldn't have different signatures.

functions in mozilla's zlib copy are renamed so as to not cause conflicts with
system zlibs. see
http://lxr.mozilla.org/seamonkey/source/modules/zlib/src/mozzconf.h#46