Go to View->Apply Themes->Get New Themes, now take any theme you want from xulplanet, as soon as you hit the Install Now link, Mozilla Crashes. This happened with the Build from Feb 2nd until today's build Feb 23th 2002. Build System: Mandrake 8.0 gcc-2.95.3 glib-2.2.2, gtk-1.2.10 Kernel: 2.4.8-ac7 Build Options: ac_add_options --prefix=/usr/lib/mozilla-097 ac_add_options --libdir=/usr/lib/mozilla-097 ac_add_options --includedir=/usr/include/mozilla-097 ac_add_options --enable-crypto ac_add_options --disable-accessibility ac_add_options --enable-mathml ac_add_options --enable-svg ac_add_options --disable-tests ac_add_options --disable-debug ac_add_options --enable-optimize="-O6 -march=i686 -mcpu=i686" ac_add_options --disable-dtd-debug ac_add_options --enable-strip ac_add_options --with-default-mozilla-five-home=/usr/lib/mozilla-097 ac_add_options --with-user-appdir=".mozilla-098" ac_add_options --enable-static ac_add_options --disable-shared I bet that this is directly related to bug 119450, and fixing that bug would also fix this bug. I marked this blocker, due to that this both things are not working I could not imagine that this should go into 0.99 GDB Output Attached
Keywords: crash, mozilla0.9.9
Target Milestone: --- → mozilla0.9.9
wfm with win2k 20020223..
Severity: blocker → critical
Target Milestone: mozilla0.9.9 → ---
Hmmh, intersting because it works on Win32 it is not a blocker ?
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.8+) Gecko/20020222 WFM. This is not a blocker because it does not block Mozilla development. Do you crash on all themes? Have you tried installing other xpi packages (stacktrace shows you are in xpinstall)?
Yes all themes I tried lead to a crash, also using: Edit->Preferences->Appearance->Content/Language Packs->Download More to install a new Language Pack leads to a crash. Give me some links, I should try and I will attach a gdb for each.
Confirmed the crash using the build options posted. Also confirmed it without the optimize flags & without the strip option. The trace looks similar to what Carsten attached.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Whiteboard: [static build]
I get the same crash when trying to install any theme from the "View->Apply Themes->Get New Themes" page. OpenVMS (static build based on Linux), 1.0-rc1.
Comment on attachment 82625 [details] [diff] [review] Build mozjs shared, even on a static build firstname.lastname@example.org This is definitely safe to do, and appears to be the issue here (while there might be better ways to solve shared/static dependencies like this in the future, they're much more complex). We still want r/sr=seawood before approval can be given.
Attachment #82625 - Flags: review+
*** Bug 119450 has been marked as a duplicate of this bug. ***
Reassigning to patch owner (I volunteer to check it in if needed). This is a wgate issue (we use static build - big perf win). CC'ing some JS/xpcom people. Looking for sr (especially from seawood) and then approval.
Assignee: hewitt → colin
Keywords: mozilla0.9.9 → mozilla1.0, patch
Whiteboard: [static build] → [static build] [WGATE]
Created attachment 82900 [details] [diff] [review] Revised patch with EXPORT_LIBRARY removed I just completed a full clean build and with the previous patch the link of mozilla-bin was still looking for libmozjs.a. This is because EXPORT_LIBRARY was set in mozjs's Makefile. So the second version of the patch removes EXPORT_LIBRARY. Now mozilla-bin links.
Attachment #82625 - Attachment is obsolete: true
Created attachment 82902 [details] [diff] [review] Make embedding tests link too The GTK embedding tests now need to link with MOZ_JS_LIBS since the js code is no longer in a static lib. Hopefully this is the final version of the patch.
Attachment #82900 - Attachment is obsolete: true
Created attachment 82908 [details] [diff] [review] MOZ_JS_LIBS for mozilla-bin static link mozilla-bin now needs MOZ_JS_LIBS for both static and shared libs.
Attachment #82902 - Attachment is obsolete: true
Added to RC3 buglist as per shaver and Asa
Comment on attachment 82908 [details] [diff] [review] MOZ_JS_LIBS for mozilla-bin static link We should be using FORCE_SHARED_LIBS (as we do for win32) rather than redefining BUILD_STATIC_LIBS & BUILD_SHARED_LIBS. Also, because JS requires NSPR in cross compiled builds, we should be linking JS before NSPR.
Attachment #82908 - Flags: needs-work+
Just a thought: are we going to run into a similar problem with our other application level libs that are also linked into some components (gfx, jsj, etc)? Should we only be linking the components statically? If so, I need to rename the configure option has it's a huge misnomer.
Created attachment 83305 [details] [diff] [review] Use FORCE_SHARED_LIB, reorder link decl & update static packaging
Attachment #82908 - Attachment is obsolete: true
> Are we going to run into a similar problem with our other application > level libs Anything which has static data and is linked into more than one shared library (or linked into one shared library and mozilla-bin) is busted, I think.
do we need to address this in windows static build too?
Cathleen: This particular problem? No. Win32 was already building js dynamically in static builds.
lets get reivew going.
Whiteboard: [static build] [WGATE] → [static build] [WGATE] need review
Comment on attachment 83305 [details] [diff] [review] Use FORCE_SHARED_LIB, reorder link decl & update static packaging r=bryner
Attachment #83305 - Flags: review+
Patch has been checked into the trunk.
Whiteboard: [static build] [WGATE] need review → [static build] [WGATE] [fixed on trunk]
we need an sr on this. drivers wants to take this for rc3. It will need to be checked in to the branch by thursday pm.
Reassigning to (correct) patch owner. Thanks for the right fix, Chris!
Assignee: colin → seawood
Priority: -- → P2
Target Milestone: --- → mozilla1.0
Comment on attachment 83305 [details] [diff] [review] Use FORCE_SHARED_LIB, reorder link decl & update static packaging a=chofmann for the 1.0 branch
Attachment #83305 - Flags: approval+
seawood, can you check this in asap to get in for 1.0?
The patch has been checked into the moz1.0.0 branch.
Whiteboard: [static build] [WGATE] [fixed on trunk] → [static build] [WGATE]
Status: NEW → RESOLVED
Last Resolved: 16 years ago
Resolution: --- → FIXED
Verified on linux redhat 7.3 (netscape trunk build: 2002-11-18-08-TRUNK), and netscape branch build (2002-11-14-07-1.0)
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.