Closed Bug 305782 Opened 14 years ago Closed 12 years ago

Please allow to use system bzip2 library

Categories

(Firefox Build System :: General, enhancement)

enhancement
Not set

Tracking

(Not tracked)

RESOLVED FIXED
mozilla1.9beta5

People

(Reporter: glandium, Assigned: glandium)

References

Details

Attachments

(1 file, 11 obsolete files)

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
Attached patch Patch for this issue (obsolete) — Splinter Review
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.
Attachment #193714 - Flags: review?(benjamin)
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.
Attachment #193714 - Flags: superreview?(cls)
Attachment #193714 - Flags: review?(benjamin)
Attachment #193714 - Flags: review+
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?
Attachment #193714 - Flags: superreview?(cls) → superreview-
Status: UNCONFIRMED → NEW
Ever confirmed: true
OS: Linux → All
Hardware: PC → All
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.
Attached patch New patch (obsolete) — Splinter Review
Updated patch to suggestions by chris.
Attachment #193714 - Attachment is obsolete: true
Attachment #194010 - Flags: review?(benjamin)
(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?
well, i'm new to the build system, could you elaborate on this or give some
pointers ?
 extern "C" NS_IMPORT_(unsigned int) BZ2_crc32Table[256];
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 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.
Attachment #194010 - Flags: review?(benjamin) → review-
Attached patch Updated patch (obsolete) — Splinter Review
Changed the pragma stuff to NS_IMPORT accordingly.
Attachment #194010 - Attachment is obsolete: true
Attachment #194286 - Flags: review?(benjamin)
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.
Attachment #194286 - Flags: review?(benjamin)
Attachment #194286 - Flags: review+
Attachment #194286 - Flags: approval1.8b4?
Flags: blocking1.8b4?
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.
Flags: blocking1.8b5? → blocking1.8b5-
Attachment #194286 - Flags: approval1.8b4?
Attached patch New patch (obsolete) — Splinter Review
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.
Attachment #194286 - Attachment is obsolete: true
Attachment #196294 - Flags: review?(benjamin)
Attachment #196294 - Flags: review?(benjamin) → review+
Did this ever get checked in?  If not, should I just go ahead and do that?
Please do
Assignee: nobody → mh
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
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?
Attached patch Updated patch (obsolete) — Splinter Review
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.
Attachment #196294 - Attachment is obsolete: true
Attachment #205404 - Flags: review?(cbiesinger)
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)
Attachment #205404 - Flags: review?(cbiesinger) → review?(benjamin)
Attachment #205404 - Flags: review?(benjamin) → review+
Attached patch additional patch (obsolete) — Splinter Review
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
Attachment #270219 - Flags: review?
Attachment #270219 - Flags: review? → review?(benjamin)
Attached patch additional patch (obsolete) — Splinter Review
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.
Attachment #270219 - Attachment is obsolete: true
Attachment #270336 - Flags: review?(bsmedberg)
Attachment #270219 - Flags: review?(benjamin)
Comment on attachment 270336 [details] [diff] [review]
additional patch

Please do not use bsmedberg@gmail.com for review requests.
Attachment #270336 - Flags: review?(bsmedberg) → review?(benjamin)
Attachment #270336 - Flags: review?(benjamin) → review+
Mike, what's the status of this bug? Were the patches ever checked-in?
(In reply to comment #24)
> Mike, what's the status of this bug? Were the patches ever checked-in?

Not that I know of.

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?
Attached patch New patch against trunk (obsolete) — Splinter Review
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
Attachment #205404 - Attachment is obsolete: true
Attachment #270336 - Attachment is obsolete: true
Attachment #292221 - Flags: review?(benjamin)
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?
Attachment #292221 - Flags: review?(benjamin) → review-
Would you suggest doing like in embedding/browser/gtk/src/gtkmozembed.h ?
That sounds reasonable, yes
Attached patch Updated patch (obsolete) — Splinter Review
Following comments #28 to #30, and updated to current trunk
Attachment #292221 - Attachment is obsolete: true
Attachment #306211 - Flags: review?(benjamin)
Attachment #306211 - Flags: review?(benjamin) → review+
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.
Attachment #306211 - Flags: approval1.9?
Comment on attachment 306211 [details] [diff] [review]
Updated patch

a1.9=beltzner
Attachment #306211 - Flags: approval1.9? → approval1.9+
This is the same patch, but adds missing variable type for BZ2_crc32Table.
Attachment #306211 - Attachment is obsolete: true
Attachment #308116 - Flags: approval1.9?
Comment on attachment 308116 [details] [diff] [review]
Brown paper bag fix

Just carry over approval. I'll land this shortly. :)
Attachment #308116 - Flags: approval1.9?
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
Status: NEW → RESOLVED
Closed: 12 years ago
Keywords: checkin-needed
Resolution: --- → FIXED
Target Milestone: --- → mozilla1.9beta5
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
Oops, sorry, I don't checkout the other-licenses stuff
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
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
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
O_o
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.
(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)
(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.
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).
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.
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 ?
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 :).
After the build fails, go to you objdir directory and find the lines shown in comment #47 in the config.status file there.
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
(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.
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.
It would probably be easier to fix the NSS_LIB part to not use continuation lines.
Attached patch Bustage fix (obsolete) — Splinter Review
Like this.
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?
Attachment #308282 - Flags: superreview?(benjamin)
Attachment #308282 - Flags: review?(kengert)
Attached patch Better patch (obsolete) — Splinter Review
This does the same thing without creating such long lines in configure.in and configure.
Attachment #308282 - Attachment is obsolete: true
Attachment #308289 - Flags: superreview?(benjamin)
Attachment #308289 - Flags: review?(kengert)
Attachment #308282 - Flags: superreview?(benjamin)
Attachment #308282 - Flags: review?(kengert)
Depends on: 421787
I decided to file a separate bug with blocker severity on this issue.

Bug 421787 filed.
Comment on attachment 308289 [details] [diff] [review]
Better patch

Patch moved to bug 421787.
Attachment #308289 - Attachment is obsolete: true
Attachment #308289 - Flags: superreview?(benjamin)
Attachment #308289 - Flags: review?(kengert)
(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!
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
Status: REOPENED → RESOLVED
Closed: 12 years ago12 years ago
Keywords: checkin-needed
Resolution: --- → FIXED
This appears to have broken Solaris builds.
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
Could you verify that replacing -L../../../../../modules/libbz2/src -lbz2 by ../../../../../modules/libbz2/src/libbz2.a in the command line works ?
(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.
BTW: With Sun Studio 12 on SunOS 5.11 (Solaris Express Developer Edition 2) this command seems to work fine.
(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 ?

I meant the "CC -o updater ..." command. Anyway, the tinderbox has been restarted and seems to build fine now.
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.
Product: Core → Firefox Build System
You need to log in before you can comment on or make changes to this bug.