305782 - Please allow to use system bzip2 library

Status: RESOLVED FIXED

(Firefox Build System :: General, enhancement)

Description

[Mike Hommey [:glandium]]

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8b3) Gecko/20050716 Debian/1.0.99+deerpark-alpha2-1 Firefox/1.0+
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8b3) Gecko/20050716 Debian/1.0.99+deerpark-alpha2-1 Firefox/1.0+

libbz2 has been introduced recently in the modules (see #296294), and is used by
the updater mozapp (and could be used for more stuff, see #173044).

It would be nice to have the build system able to use the library installed on
the system, and to dynamically link to it.

Patch is coming.

Reproducible: Always

Comment 1

[Mike Hommey [:glandium]]

Attachment: Patch for this issue

I don't know if it's common use to include the configure file in the patch...

I'm quite new to the mozilla build system, and didn't find a strict rule for
naming variables, so it's a mix between what has been done for zlib, libpng and
libjpeg, and what has been done for more recent stuff like cairo.

Comment 2

[Benjamin Smedberg]

Comment on attachment 193714 [details] [diff] [review]
Patch for this issue

You don't need to include configure in your patches, our CVS system autocommits
configure when configure.in changes.

Comment 3

[cls]

Comment on attachment 193714 [details] [diff] [review]
Patch for this issue

Since we're using REQUIRES to pull in the bz2 headers & they aren't guaranteed
to be the same as the version installed on the system, you'll need a
BZ2_REQUIRES variable like we have for zlib/png/jpeg. 

In toolkit/mozapps/update/src/updater/Makefile.in , I would recommend appending
MOZ_BZ2_LIBS to LIBS instead of LDFLAGS.

What's the point of the pragma changes?

Comment 4

[Mike Hommey [:glandium]]

the pragma thing is required for correct linking with gcc 4.0 which doesn't find
the symbols otherwise. It's the same as what does the system wrappers includes,
except that since the variable isn't imported from an include file, it is not
correctly wrapped.

I'll take a look at the REQUIRES thing later on.

Comment 5

[Mike Hommey [:glandium]]

Attachment: New patch

Updated patch to suggestions by chris.

Comment 6

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

(In reply to comment #4)
> the pragma thing is required for correct linking with gcc 4.0 which doesn't find
> the symbols otherwise.

isn't that what NS_IMPORT_ is for?

Comment 7

[Mike Hommey [:glandium]]

well, i'm new to the build system, could you elaborate on this or give some
pointers ?

Comment 8

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

 extern "C" NS_IMPORT_(unsigned int) BZ2_crc32Table[256];

Comment 9

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

or if that would cause problems on windows (I don't know if it would):
 extern "C" NS_EXTERNAL_VIS_(unsigned int) BZ2_crc32Table[256];

Comment 10

[Benjamin Smedberg]

Comment on attachment 194010 [details] [diff] [review]
New patch

r- based on the question about the visibility pragma and NS_IMPORT... please
re-request review on this if NS_IMPORT is wrong.

Comment 11

[Mike Hommey [:glandium]]

Attachment: Updated patch

Changed the pragma stuff to NS_IMPORT accordingly.

Comment 12

[Benjamin Smedberg]

Comment on attachment 194286 [details] [diff] [review]
Updated patch

Please land this on trunk, and if it doesn't break anything the 1.8 branch
approval should be a snap.

Comment 13

[Asa Dotzler [:asa]]

not going to block on. if this gets landed on the trunk and proves itself in
time to make one of our releases, please request approval then. Thanks.

Comment 14

[Mike Hommey [:glandium]]

Attachment: New patch

The previous patch was actually wrong for 2 things : it used NS_IMPORT instead
of NS_IMPORT_, and nscore.h, needed for the macro, was not included. The new
patch is now correct.

Comment 15

[Boris Zbarsky [:bzbarsky]]

Did this ever get checked in?  If not, should I just go ahead and do that?

Comment 16

[Mike Hommey [:glandium]]

Please do

Comment 17

[Boris Zbarsky [:bzbarsky]]

I checked this in, then had to back it out because it didn't link on Windows.  The linker error messages are:

/cygdrive/c/builds/tinderbox/Fx-Trunk/WINNT_5.2_Depend/mozilla/build/cygwin-wrapper link -NOLOGO -OUT:updater.exe -PDB:updater.pdb -SUBSYSTEM:WINDOWS -DEBUG -OPT:REF -OPT:nowin98  updater.obj bspatch.obj archivereader.obj progressui_win.obj ./module.res ../../../../../dist/lib/mar.lib  -L../../../../../dist/lib -lbz2  kernel32.lib user32.lib gdi32.lib winmm.lib wsock32.lib advapi32.lib comctl32.lib ws2_32.lib
LINK : warning LNK4044: unrecognized option "L../../../../../dist/lib"; ignored
LINK : warning LNK4044: unrecognized option "lbz2"; ignored
updater.obj : error LNK2001: unresolved external symbol __imp__BZ2_crc32Table
archivereader.obj : error LNK2001: unresolved external symbol _BZ2_bzDecompressEnd@4
archivereader.obj : error LNK2001: unresolved external symbol _BZ2_bzDecompress@4
archivereader.obj : error LNK2001: unresolved external symbol _BZ2_bzDecompressInit@12
updater.exe : fatal error LNK1120: 4 unresolved externals
make[8]: *** [updater.exe] Error 96

Comment 18

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

sounds like configure.in needs some more changes, similar to what MOZ_ZLIB_LIBS does. it also looks to me like the other system libs use EXTRA_DSO_LDOPTS in the makefile rather than LIBS, does that make a difference?

Comment 19

[Mike Hommey [:glandium]]

Attachment: Updated patch

It would be EXTRA_LIBS instead of EXTRA_DSO_LDOPTS, since we build a PROGRAM, not a SHARED_LIBRARY.
I adjusted the patch for that and the configure stuff. It should now be okay on windows.

Comment 20

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

Comment on attachment 205404 [details] [diff] [review]
Updated patch

+REQUIRES = libmar \
+	   $(BZ2_REQUIRES)

I'd add a $(NULL) here too (better diff output in case someone has to add another REQUIRES at some point)

Comment 21

[Mike Hommey [:glandium]]

Attachment: additional patch

Additional patch, necessary to properly build with gcc 4.2, which ends up using the system wrappers instead of the -fvisibility=hidden flag. Without this patch, the build fails with the following error:
js/src/js.c:149: undefined reference to `readline'
js/src/js.c:153: undefined reference to `add_history'
/usr/bin/ld: js: hidden symbol `readline' isn't defined
/usr/bin/ld: final link failed: Nonrepresentable section on output
collect2: ld returned 1 exit status

Comment 22

[Mike Hommey [:glandium]]

Attachment: additional patch

Forget about my last comment, it was the wrong bug...

Anyways, the reason for this additional patch is similar: a missing system wrapper for visibility.

Comment 23

[Benjamin Smedberg]

Comment on attachment 270336 [details] [diff] [review]
additional patch

Please do not use [e-mail] for review requests.

Comment 24

[Reed Loden [:reed]]

Mike, what's the status of this bug? Were the patches ever checked-in?

Comment 25

[Mike Hommey [:glandium]]

(In reply to comment #24)
> Mike, what's the status of this bug? Were the patches ever checked-in?

Not that I know of.

Comment 26

[Reed Loden [:reed]]

If you'll unbitrot attachment 205404 [details] [diff] [review], I can try to help you drive it into the tree. I doubt attachment 270336 [details] [diff] [review] is bitrotted, so it should still be fine. How's that sound?

Comment 27

[Mike Hommey [:glandium]]

Attachment: New patch against trunk

This is a new patch replacing both previous ones, with all updates necessary for trunk. AFAICT, it works with or without system bz2. Note the metrics extension doesn't build unless you apply http://matrix.senecac.on.ca/%7Esljung/metrics/metrics.patch

Comment 28

[Benjamin Smedberg]

Comment on attachment 292221 [details] [diff] [review]
New patch against trunk

This is fine except for including nscore.h in updater.cpp... that will bring in unwanted imports... can we find a simpler way to declare BZ2_crc32Table as visibility-public?

Comment 29

[Mike Hommey [:glandium]]

Would you suggest doing like in embedding/browser/gtk/src/gtkmozembed.h ?

Comment 30

[Benjamin Smedberg]

That sounds reasonable, yes

Comment 31

[Mike Hommey [:glandium]]

Attachment: Updated patch

Following comments #28 to #30, and updated to current trunk

Comment 32

[Reed Loden [:reed]]

Comment on attachment 306211 [details] [diff] [review]
Updated patch

Simple patch to allow Linux distros to use system bz2 instead of the one in the tree.

Comment 33

[Mike Beltzner [:beltzner, not reading bugmail]]

Comment on attachment 306211 [details] [diff] [review]
Updated patch

a1.9=beltzner

Comment 34

[Mike Hommey [:glandium]]

Attachment: Brown paper bag fix

This is the same patch, but adds missing variable type for BZ2_crc32Table.

Comment 35

[Reed Loden [:reed]]

Comment on attachment 308116 [details] [diff] [review]
Brown paper bag fix

Just carry over approval. I'll land this shortly. :)

Comment 36

[Reed Loden [:reed]]

Checking in configure.in;
/cvsroot/mozilla/configure.in,v  <--  configure.in
new revision: 1.1948; previous revision: 1.1947
done
Checking in toolkit/toolkit-tiers.mk;
/cvsroot/mozilla/toolkit/toolkit-tiers.mk,v  <--  toolkit-tiers.mk
new revision: 1.13; previous revision: 1.12
done
Checking in config/Makefile.in;
/cvsroot/mozilla/config/Makefile.in,v  <--  Makefile.in
new revision: 3.146; previous revision: 3.145
done
Checking in config/autoconf.mk.in;
/cvsroot/mozilla/config/autoconf.mk.in,v  <--  autoconf.mk.in
new revision: 3.454; previous revision: 3.453
done
Checking in config/system-headers;
/cvsroot/mozilla/config/system-headers,v  <--  system-headers
new revision: 3.37; previous revision: 3.36
done
Checking in extensions/metrics/build/Makefile.in;
/cvsroot/mozilla/extensions/metrics/build/Makefile.in,v  <--  Makefile.in
new revision: 1.8; previous revision: 1.7
done
Checking in extensions/metrics/src/Makefile.in;
/cvsroot/mozilla/extensions/metrics/src/Makefile.in,v  <--  Makefile.in
new revision: 1.22; previous revision: 1.21
done
Checking in extensions/metrics/test/Makefile.in;
/cvsroot/mozilla/extensions/metrics/test/Makefile.in,v  <--  Makefile.in
new revision: 1.6; previous revision: 1.5
done
Checking in toolkit/mozapps/update/src/updater/Makefile.in;
/cvsroot/mozilla/toolkit/mozapps/update/src/updater/Makefile.in,v  <--  Makefile.in
new revision: 1.24; previous revision: 1.23
done
Checking in toolkit/mozapps/update/src/updater/updater.cpp;
/cvsroot/mozilla/toolkit/mozapps/update/src/updater/updater.cpp,v  <--  updater.cpp
new revision: 1.34; previous revision: 1.33
done

Comment 37

[Reed Loden [:reed]]

You forgot to modify other-licenses/bsdiff/Makefile.in... I checked-in a bustage fix that I think will fix it.

Checking in other-licenses/bsdiff/Makefile.in;
/cvsroot/mozilla/other-licenses/bsdiff/Makefile.in,v  <--  Makefile.in
new revision: 1.5; previous revision: 1.4
done

Comment 38

[Mike Hommey [:glandium]]

Oops, sorry, I don't checkout the other-licenses stuff

Comment 39

[Reed Loden [:reed]]

You also needed to modify toolkit/toolkit-makefiles.sh to conditionally include the in-tree libbz2.

Checking in toolkit/toolkit-makefiles.sh;
/cvsroot/mozilla/toolkit/toolkit-makefiles.sh,v  <--  toolkit-makefiles.sh
new revision: 1.14; previous revision: 1.13
done

Comment 40

[Reed Loden [:reed]]

Had to back this out for build bustage on win32.

make -f client.mk MOZ_OBJDIR=obj-fx-trunk CONFIGURE_ENV_ARGS='' build_all_depend
make -j5 -C obj-fx-trunk alldep
make[1]: Entering directory `/e/builds/tinderbox/Fx-Trunk-Memtest/WINNT_5.2_Depend/mozilla/obj-fx-trunk'
Makefile:69: /e/builds/tinderbox/Fx-Trunk-Memtest/WINNT_5.2_Depend/mozilla//build.mk: No such file or directory
make[1]: *** No rule to make target `/e/builds/tinderbox/Fx-Trunk-Memtest/WINNT_5.2_Depend/mozilla//build.mk'.  Stop.
make[1]: Leaving directory `/e/builds/tinderbox/Fx-Trunk-Memtest/WINNT_5.2_Depend/mozilla/obj-fx-trunk'
make: *** [alldep] Error 2

Comment 41

[Mike Hommey [:glandium]]

O_o

Comment 42

[Bill Gianopoulos [:WG9s]]

Comment on attachment 308116 [details] [diff] [review]
Brown paper bag fix

>+if test -z "$BZ2_DIR" -o "$BZ2_DIR" = no; then
>+    SYSTEM_BZ2=
>+else
>+    AC_CHECK_LIB(bz2, BZ2_bzread, [SYSTEM_BZ2=1 BZ2_LIBS="-lbz2"],
>+	[SYSTEM_BZ2= BZ2_CFLAGS= BZ2_LIBS=], $BZ2_LIBS)
>+fi

The AC_CHECK_LIB above would appear to be incorrect.  AC_CHECK_LIB appears to take the first parameter and the second and concatenate them with an '_' between them, so this ends up using bz2_BZ2_bzread.  I am pretty sure that is NOT what is intended here.

Comment 43

[Mike Hommey [:glandium]]

(In reply to comment #42)
> (From update of attachment 308116 [details] [diff] [review])
> >+if test -z "$BZ2_DIR" -o "$BZ2_DIR" = no; then
> >+    SYSTEM_BZ2=
> >+else
> >+    AC_CHECK_LIB(bz2, BZ2_bzread, [SYSTEM_BZ2=1 BZ2_LIBS="-lbz2"],
> >+	[SYSTEM_BZ2= BZ2_CFLAGS= BZ2_LIBS=], $BZ2_LIBS)
> >+fi
> 
> The AC_CHECK_LIB above would appear to be incorrect.  AC_CHECK_LIB appears to
> take the first parameter and the second and concatenate them with an '_'
> between them, so this ends up using bz2_BZ2_bzread.  I am pretty sure that is
> NOT what is intended here.

Erm, AC_CHECK_LIB is supposed to check for the existance of the function named as the second argument in the library named as the first argument (-lbz2, here)

Comment 44

[Bill Gianopoulos [:WG9s]]

(In reply to comment #43)
> (In reply to comment #42)
> > (From update of attachment 308116 [details] [diff] [review] [details])
> > >+if test -z "$BZ2_DIR" -o "$BZ2_DIR" = no; then
> > >+    SYSTEM_BZ2=
> > >+else
> > >+    AC_CHECK_LIB(bz2, BZ2_bzread, [SYSTEM_BZ2=1 BZ2_LIBS="-lbz2"],
> > >+	[SYSTEM_BZ2= BZ2_CFLAGS= BZ2_LIBS=], $BZ2_LIBS)
> > >+fi
> > 
> > The AC_CHECK_LIB above would appear to be incorrect.  AC_CHECK_LIB appears to
> > take the first parameter and the second and concatenate them with an '_'
> > between them, so this ends up using bz2_BZ2_bzread.  I am pretty sure that is
> > NOT what is intended here.
> 
> Erm, AC_CHECK_LIB is supposed to check for the existance of the function named
> as the second argument in the library named as the first argument (-lbz2, here)
> 

I was referring specifically to this line in configure:

ac_lib_var=`echo bz2'_'BZ2_bzread | sed 'y%./+-%__p_%'`

which ends up echoing bz2_BZ2_bzread.

However, I think you are right and it is not the issue here.

Comment 45

[Frank Wein [:mcsmurf]]

BTW: Other problems this patch caused earlier in the build process (I think they were from this patch as it worked after backing out):
creating config/autoconf.mk
sed: file conftest.s5 line 91: Unterminated `s' command
sed: file conftest.s6 line 1: Unknown command: ``(''
creating config/doxygen.cfg
sed: file conftest.s5 line 91: Unterminated `s' command
sed: file conftest.s6 line 1: Unknown command: ``(''
creating xpfe/global/buildconfig.html
sed: file conftest.s5 line 91: Unterminated `s' command
sed: file conftest.s6 line 1: Unknown command: ``(''
creating toolkit/content/buildconfig.html
sed: file conftest.s5 line 91: Unterminated `s' command
sed: file conftest.s6 line 1: Unknown command: ``(''
creating gfx/cairo/cairo/src/cairo-features.h
sed: file conftest.s5 line 91: Unterminated `s' command
sed: file conftest.s6 line 1: Unknown command: ``(''
creating netwerk/necko-config.h
creating xpcom/xpcom-config.h
creating xpcom/xpcom-private.h
[...]

autoconf.mk, doxygen.cfg, etc. were then empty of course (and the build failed later with the error above).

Comment 46

[Mike Hommey [:glandium]]

There is nothing in the changes introduced by this patch, that adds a sed 's' command. I fail to see how this can be related.

Comment 47

[Mike Hommey [:glandium]]

ah, there is, actually...

s%@SYSTEM_BZ2@%$SYSTEM_BZ2%g 
s%@BZ2_CFLAGS@%$BZ2_CFLAGS%g
s%@BZ2_LIBS@%$BZ2_LIBS%g
s%@MOZ_BZ2_CFLAGS@%$MOZ_BZ2_CFLAGS%g
s%@MOZ_BZ2_LIBS@%$MOZ_BZ2_LIBS%g

Do you know the value for these variables when it fails ?

Comment 48

[Frank Wein [:mcsmurf]]

When I insert these lines right here http://lxr.mozilla.org/seamonkey/source/configure#20967:
echo "systen_bz2: $SYSTEM_BZ2"
echo "bz2_cflgags: $BZ2_CFLAGS"
echo "bz2_libs: $BZ2_LIBS"
echo "MOZ_BZ2_CFLAGS: $MOZ_BZ2_CFLAGS"
echo "MOZ_BZ2_LIBS: $MOZ_BZ2_LIBS"

I get this as output:
systen_bz2:
bz2_cflgags:
bz2_libs:
MOZ_BZ2_CFLAGS:
MOZ_BZ2_LIBS: $(call EXPAND_LIBNAME_PATH,bz2,$(DEPTH)/modules/libbz2/src)

If my echo commands are at the wrong place or wrong at all, please tell me :).

Comment 49

[Bill Gianopoulos [:WG9s]]

After the build fails, go to you objdir directory and find the lines shown in comment #47 in the config.status file there.

Comment 50

[Frank Wein [:mcsmurf]]

Yeah, those are the same.
I think I found the problem though after taking a look at conftest.s5 and conftest.s6 (you can make a copy of these files while config.status is running):
With your patch the last few lines of conftest.s5 are:
s%@MOZ_NATIVE_NSPR@%%g
s%@NSS_DEP_LIBS@%\\\
        $(LIBXUL_DIST)/lib/$(LIB_PREFIX)crmf.$(LIB_SUFFIX) \\\
        $(LIBXUL_DIST)/lib/$(DLL_PREFIX)smime3$(DLL_SUFFIX) \\\

and of conftest.s6:
        $(LIBXUL_DIST)/lib/$(DLL_PREFIX)ssl3$(DLL_SUFFIX) \\\
        $(LIBXUL_DIST)/lib/$(DLL_PREFIX)nss3$(DLL_SUFFIX) \\\
        $(LIBXUL_DIST)/lib/$(DLL_PREFIX)nssutil3$(DLL_SUFFIX) \\\
        $(LIBXUL_DIST)/lib/$(DLL_PREFIX)softokn3$(DLL_SUFFIX)%g
s%@MOZ_NATIVE_NSS@%%g

So the conftest program seems to cut the s%@NSS_DEP_LIBS@%[...] command in two parts in puts in two different files, it looks like it always cuts of after 90 lines. When I delete the new bz2 files though from config.status, the last few lines of conftest.s5 are:
s%@NSS_DEP_LIBS@%\\\
        $(LIBXUL_DIST)/lib/$(LIB_PREFIX)crmf.$(LIB_SUFFIX) \\\
        $(LIBXUL_DIST)/lib/$(DLL_PREFIX)smime3$(DLL_SUFFIX) \\\
        $(LIBXUL_DIST)/lib/$(DLL_PREFIX)ssl3$(DLL_SUFFIX) \\\
        $(LIBXUL_DIST)/lib/$(DLL_PREFIX)nss3$(DLL_SUFFIX) \\\
        $(LIBXUL_DIST)/lib/$(DLL_PREFIX)nssutil3$(DLL_SUFFIX) \\\
        $(LIBXUL_DIST)/lib/$(DLL_PREFIX)softokn3$(DLL_SUFFIX)%g
s%@MOZ_NATIVE_NSS@%%g

and first lines of conftest.s6 are:
s%@COMPILE_CFLAGS@%$(ACDEFINES) -D_MOZILLA_CONFIG_H_ -DMOZILLA_CLIENT%g
s%@COMPILE_CXXFLAGS@%$(ACDEFINES) -D_MOZILLA_CONFIG_H_ -DMOZILLA_CLIENT%g

So your patch just had the problem that it moves the NSS sed command into this 90 lines limit. It looks like the 90 lines limit gets set under http://lxr.mozilla.org/seamonkey/source/configure#21506

Comment 51

[Frank Wein [:mcsmurf]]

(In reply to comment #50)
[...]
> and of conftest.s6:
>         $(LIBXUL_DIST)/lib/$(DLL_PREFIX)ssl3$(DLL_SUFFIX) \\\
>         $(LIBXUL_DIST)/lib/$(DLL_PREFIX)nss3$(DLL_SUFFIX) \\\
>         $(LIBXUL_DIST)/lib/$(DLL_PREFIX)nssutil3$(DLL_SUFFIX) \\\
>         $(LIBXUL_DIST)/lib/$(DLL_PREFIX)softokn3$(DLL_SUFFIX)%g
> s%@MOZ_NATIVE_NSS@%%g
[...]

The first few lines of conftest.s6 were meant here.

Comment 52

[Bill Gianopoulos [:WG9s]]

So the real issue here is that the code that does the splitting needs to be modified to not do the split in the middle of a multi-line sed command.

Comment 53

[Bill Gianopoulos [:WG9s]]

It would probably be easier to fix the NSS_LIB part to not use continuation lines.

Comment 54

[Bill Gianopoulos [:WG9s]]

Attachment: Bustage fix

Like this.

Comment 55

[Bill Gianopoulos [:WG9s]]

So, it appears the bustage was actually caused by the code for Bug 255408, and is like a time-bomb waiting to go off whenever someone else is making configure changes.  I wonder if other build system changes ran into this in the past and never got checked in because this was never figured out before.

Can this be fixed here, or do we need to file another bug on fixing the NSS section to not use continuation lines and make this bug dependent on that?

Comment 56

[Bill Gianopoulos [:WG9s]]

Attachment: Better patch

This does the same thing without creating such long lines in configure.in and configure.

Comment 57

[Bill Gianopoulos [:WG9s]]

I decided to file a separate bug with blocker severity on this issue.

Bug 421787 filed.

Comment 58

[Bill Gianopoulos [:WG9s]]

Comment on attachment 308289 [details] [diff] [review]
Better patch

Patch moved to bug 421787.

Comment 59

[Bill Gianopoulos [:WG9s]]

(In reply to comment #50)
> So the conftest program seems to cut the s%@NSS_DEP_LIBS@%[...] command in two
> parts in puts in two different files, it looks like it always cuts of after 90

> So your patch just had the problem that it moves the NSS sed command into this
> 90 lines limit. It looks like the 90 lines limit gets set under
> http://lxr.mozilla.org/seamonkey/source/configure#21506
> 

Good catch!

Comment 60

[Reed Loden [:reed]]

Let's try this again.

Checking in configure.in;
/cvsroot/mozilla/configure.in,v  <--  configure.in
new revision: 1.1953; previous revision: 1.1952
done
Checking in config/Makefile.in;
/cvsroot/mozilla/config/Makefile.in,v  <--  Makefile.in
new revision: 3.148; previous revision: 3.147
done
Checking in config/autoconf.mk.in;
/cvsroot/mozilla/config/autoconf.mk.in,v  <--  autoconf.mk.in
new revision: 3.456; previous revision: 3.455
done
Checking in config/system-headers;
/cvsroot/mozilla/config/system-headers,v  <--  system-headers
new revision: 3.39; previous revision: 3.38
done
Checking in toolkit/toolkit-makefiles.sh;
/cvsroot/mozilla/toolkit/toolkit-makefiles.sh,v  <--  toolkit-makefiles.sh
new revision: 1.16; previous revision: 1.15
done
Checking in toolkit/toolkit-tiers.mk;
/cvsroot/mozilla/toolkit/toolkit-tiers.mk,v  <--  toolkit-tiers.mk
new revision: 1.15; previous revision: 1.14
done
Checking in toolkit/mozapps/update/src/updater/Makefile.in;
/cvsroot/mozilla/toolkit/mozapps/update/src/updater/Makefile.in,v  <--  Makefile.in
new revision: 1.28; previous revision: 1.27
done
Checking in toolkit/mozapps/update/src/updater/updater.cpp;
/cvsroot/mozilla/toolkit/mozapps/update/src/updater/updater.cpp,v  <--  updater.cpp
new revision: 1.36; previous revision: 1.35
done
Checking in extensions/metrics/build/Makefile.in;
/cvsroot/mozilla/extensions/metrics/build/Makefile.in,v  <--  Makefile.in
new revision: 1.10; previous revision: 1.9
done
Checking in extensions/metrics/src/Makefile.in;
/cvsroot/mozilla/extensions/metrics/src/Makefile.in,v  <--  Makefile.in
new revision: 1.24; previous revision: 1.23
done
Checking in extensions/metrics/test/Makefile.in;
/cvsroot/mozilla/extensions/metrics/test/Makefile.in,v  <--  Makefile.in
new revision: 1.8; previous revision: 1.7
done
Checking in other-licenses/bsdiff/Makefile.in;
/cvsroot/mozilla/other-licenses/bsdiff/Makefile.in,v  <--  Makefile.in
new revision: 1.7; previous revision: 1.6
done

Comment 61

[Bill Gianopoulos [:WG9s]]

This appears to have broken Solaris builds.

Comment 62

[Bill Gianopoulos [:WG9s]]

gmake[8]: Entering directory `/export/home/mrbld/tinderbox/SunOS_5.11_Depend/mozilla/toolkit/mozapps/update/src/updater'
CC -o updater  -norunpath -xlibmil -xlibmopt -lCrun -lCstd -xbuiltin=%all -features=tmplife -norunpath -mt -I/usr/include/gtk-2.0 -I/usr/lib/gtk-2.0/include -I/usr/include/atk-1.0 -I/usr/include/cairo -I/usr/include/pango-1.0 -I/usr/X11/include -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -I/usr/sfw/include -I/usr/sfw/include/freetype2 -I/usr/include/libpng12 -I/usr/include/gtk-unix-print-2.0    -DNDEBUG -DTRIMMED -xO4   updater.o bspatch.o archivereader.o progressui_gtk.o readstrings.o   -lpthread -M /usr/lib/ld/map.noexstk -xildoff -z lazyload -z combreloc -z ignore -L/usr/lib -L/usr/sfw/lib -L/usr/lib/X11 -R/usr/lib/X11 -z ignore -R '$ORIGIN:$ORIGIN/..'  -R ../../../../../dist/bin  -L../../../../../dist/bin -L../../../../../dist/lib ../../../../../modules/libmar/src/libmar.a -L../../../../../modules/libbz2/src -lbz2  -lsocket -ldl -lm  -R/usr/X11/lib -L/usr/X11/lib -lgtk-x11-2.0 -latk-1.0 -lgdk-x11-2.0 -lXi -lXext -lX11 -lgdk_pixbuf-2.0 -lm -lmlib -lpangocairo-1.0 -lfontconfig -lXrandr -lXcursor -lXcomposite -lXdamage -lpango-1.0 -lcairo -lgmodule-2.0 -lXfixes -lgobject-2.0 -lglib-2.0        
Undefined			first referenced
 symbol  			    in file
BZ2_crc32Table                      updater.o
ld: fatal: Symbol referencing errors. No output written to updater

Comment 63

[Mike Hommey [:glandium]]

Could you verify that replacing -L../../../../../modules/libbz2/src -lbz2 by ../../../../../modules/libbz2/src/libbz2.a in the command line works ?

Comment 64

[Bill Gianopoulos [:WG9s]]

(In reply to comment #63)
> Could you verify that replacing -L../../../../../modules/libbz2/src -lbz2 by
> ../../../../../modules/libbz2/src/libbz2.a in the command line works ?
> 

This is not an error I am encountering as I have no facility to do a Solaris build.  I was merely reporting the issue the Seamonkey-ports and firefox-ports build system are encountering.  That log snippet is from one of the tinderbox machine builds.

Comment 65

[Frank Wein [:mcsmurf]]

BTW: With Sun Studio 12 on SunOS 5.11 (Solaris Express Developer Edition 2) this command seems to work fine.

Comment 66

[Mike Hommey [:glandium]]

(In reply to comment #65)
> BTW: With Sun Studio 12 on SunOS 5.11 (Solaris Express Developer Edition 2)
> this command seems to work fine.

Which command do you mean ?

Comment 67

[Frank Wein [:mcsmurf]]

I meant the "CC -o updater ..." command. Anyway, the tinderbox has been restarted and seems to build fine now.

Comment 68

[Bill Gianopoulos [:WG9s]]

Yes, the firefox-ports and Seamonkey-ports Solaris builds are all green now, Which is thie issue I had raised in the first place.

Therefore, we are done here.