Closed Bug 415928 Opened 12 years ago Closed 12 years ago

fix packaging of CRT with jemalloc

Categories

(Firefox Build System :: General, defect)

x86
Windows XP
defect
Not set

Tracking

(Not tracked)

RESOLVED FIXED
mozilla1.9beta4

People

(Reporter: ted, Assigned: ted)

References

Details

Attachments

(5 files, 2 obsolete files)

We're currently shipping both our custom CRT (mozcrt19.dll) and the standard CRT DLLs on trunk.  We should fix this by:

1) Unsetting WIN32_REDIST_DIR on the nightly box (in tinder-config.pl?)
2) Adding the files to removed-files.in #if MOZ_MEMORY

Should save us almost 1Mb in size (before compression).
Attached patch tinderbox configSplinter Review
Assignee: nobody → ted.mielczarek
Status: NEW → ASSIGNED
Attachment #301668 - Flags: review?(rhelmer)
Attached patch packaging patchSplinter Review
Attachment #301669 - Flags: review?(benjamin)
Attachment #301668 - Flags: review?(rhelmer) → review+
Attachment #301668 - Attachment description: tinderbox config → tinderbox config [checked in]
Comment on attachment 301668 [details] [diff] [review]
tinderbox config

So it turns out we're still actually linked to msvcp80.dll, so I backed this out and clobbered so we don't break a whole bunch of nightly testers.
Attachment #301668 - Attachment description: tinderbox config [checked in] → tinderbox config
Just to have a place to stick this:
Apparently the way to fix our dependency on msvcp80.dll would be to use "-D_STATIC_CPPLIB"
Attachment #301669 - Flags: review?(benjamin) → review+
This doesn't fix NSPR/NSS, they still wind up with manifests.  I can't seem to get the LDFLAGS to take, I'm not sure what's going on there.  I tried setting _SUBDIR_LDFLAGS and it didn't appear to work.
Attachment #303146 - Flags: review?(benjamin)
Attachment #303146 - Flags: review?(benjamin) → review+
Comment on attachment 303146 [details] [diff] [review]
fix CRT linkage [checked in]

This gets us partway to not having to ship the microsoft CRT alongside our custom CRT.
Attachment #303146 - Flags: approval1.9?
Attachment #303146 - Flags: approval1.9? → approval1.9+
Comment on attachment 303146 [details] [diff] [review]
fix CRT linkage [checked in]

Checked this in, still need to sort out how to get NSPR and NSS to play ball.
Attachment #303146 - Attachment description: fix CRT linkage → fix CRT linkage [checked in]
Depends on: 418687
With the patches from bug 418687 and bug 418613, and setting DLLFLAGS=-MANIFEST:NO in my environment, I have a build without the MSVCRT dlls that works on a machine without the runtime installed.
Depends on: 418613
Attached patch make nspr/nss play along (obsolete) — Splinter Review
Ok, this is the final piece.
Attachment #304995 - Flags: review?
Attachment #304995 - Flags: review? → review?(benjamin)
Attachment #304995 - Flags: review?(benjamin) → review+
Comment on attachment 304995 [details] [diff] [review]
make nspr/nss play along

actually, please do

DLLFLAGS="$DLLFLAGS -MANIFEST:NO" in case there are pre-set dllflags.
Attachment #304995 - Flags: approval1.9?
Attachment #301669 - Flags: approval1.9?
Comment on attachment 301669 [details] [diff] [review]
packaging patch

a1.9+=damons
Attachment #301669 - Flags: approval1.9? → approval1.9+
Comment on attachment 304995 [details] [diff] [review]
make nspr/nss play along

a1.9+=damons
Attachment #304995 - Flags: approval1.9? → approval1.9+
Would like to get these in, but I don't have time to watch the tree anytime soon.  Probably needs a clobber when they're checked in, so either do it in the morning before a clobber, or clobber when they're checked in.  All three patches on this bug should be checked in.
Keywords: checkin-needed
Checking in browser/installer/removed-files.in;
/cvsroot/mozilla/browser/installer/removed-files.in,v  <--  removed-files.in
new revision: 1.36; previous revision: 1.35
done
Checking in configure.in;
/cvsroot/mozilla/configure.in,v  <--  configure.in
new revision: 1.1940; previous revision: 1.1939
done
Checking in tools/tinderbox-configs/firefox/win32/mozconfig;
/cvsroot/mozilla/tools/tinderbox-configs/firefox/win32/mozconfig,v  <--  mozconfig
new revision: 1.16; previous revision: 1.15
done
Checking in tools/tinderbox-configs/firefox/win32/CLOBBER;
/cvsroot/mozilla/tools/tinderbox-configs/firefox/win32/CLOBBER,v  <--  CLOBBER
new revision: 1.67; previous revision: 1.66
done
Status: ASSIGNED → RESOLVED
Closed: 12 years ago
Keywords: checkin-needed
Resolution: --- → FIXED
Target Milestone: --- → mozilla1.9beta4
I've backed this out because it appears to be the cause of the firefox build no longer running. For some reason the clobber builds were just fine however the regular build that followed fails to run with "The application failed to initialise properly 0xc0150002".

Using dependency walker showed the following errors, not sure if they are relevant:

Error: The Side-by-Side configuration information for "c:\documents and settings\dave\desktop\firefox\SMIME3.DLL" contains errors. This application has failed to start because the application configuration is incorrect. Reinstalling the application may fix this problem (14001).
Error: The Side-by-Side configuration information for "c:\documents and settings\dave\desktop\firefox\NSS3.DLL" contains errors. This application has failed to start because the application configuration is incorrect. Reinstalling the application may fix this problem (14001).
Error: The Side-by-Side configuration information for "c:\documents and settings\dave\desktop\firefox\NSSUTIL3.DLL" contains errors. This application has failed to start because the application configuration is incorrect. Reinstalling the application may fix this problem (14001).
Error: The Side-by-Side configuration information for "c:\documents and settings\dave\desktop\firefox\SSL3.DLL" contains errors. This application has failed to start because the application configuration is incorrect. Reinstalling the application may fix this problem (14001).
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Ugh, it looks like NSS didn't take those changes.  Must have been something wrong in my tests.  I'll take another look.
Ah, I must have left DLLFLAGS set in my environment.  My patch didn't work because NSS doesn't have configure, so setting that variable in the environment in configure doesn't do anything for it.  It needs to be set as a make variable to get passed down.  I have a new patch, testing it now.
Status: REOPENED → ASSIGNED
Attached patch make nspr/nss play along, v2 (obsolete) — Splinter Review
Ok, this actually works.
Attachment #304995 - Attachment is obsolete: true
Attachment #305398 - Flags: review?(benjamin)
Comment on attachment 305398 [details] [diff] [review]
make nspr/nss play along, v2

I don't think we should export this into the environment. Instead, explicitly override DLLFLAGS when building NSS, here:

http://mxr.mozilla.org/mozilla/source/security/manager/Makefile.in#155
Attachment #305398 - Flags: review?(benjamin) → review-
Sadly, that doesn't work, because then the NSS makefiles can't append to it:
http://www.gnu.org/software/make/manual/make.html#Override-Directive

if we do |make DLLFLAGS=-FOO|, and the NSS makefile does DLLFLAGS+=-BAR, DLLFLAGS will only ever contain "-FOO". This breaks things pretty badly.  :-/
Ok, this is what we compromised on.  We can't pass it in DEFAULT_GMAKE_FLAGS, because then the NSS makefiles can't append to it, which breaks their build system.  Exporting DLLFLAGS to the environment in security/manager/Makefile.in is less intrusive than doing it in autoconf.mk.in.
Attachment #305398 - Attachment is obsolete: true
Attachment #305557 - Flags: review?(benjamin)
Attachment #305557 - Flags: review?(benjamin) → review+
Attachment #305557 - Flags: approval1.9?
Comment on attachment 305557 [details] [diff] [review]
make nspr/nss play along, v3 [checked in]

a1.9+=damons
Attachment #305557 - Flags: approval1.9? → approval1.9+
Attachment #305557 - Attachment description: make nspr/nss play along, v3 → make nspr/nss play along, v3 [checked in]
I'll check in the tinderbox config and packaging bits tomorrow in time for the nightly, since that will need a clobber.
I missed checking this in for the nightly, but I downloaded the nightly, deleted the microsoft CRT, and it still ran fine in my test VM. I checked the packaging bits back in, so we should be ok for the next clobber.
Status: ASSIGNED → RESOLVED
Closed: 12 years ago12 years ago
Resolution: --- → FIXED
Worked this out with ted on IRC.
Attachment #305800 - Attachment description: bustage fix → bustage fix (checked in)
Duplicate of this bug: 419648
firefox-3.0b4pre.en-US.win32.installer.exe	26-Feb-2008 05:57 	6.5M
firefox-3.0b4pre.en-US.win32.zip	26-Feb-2008 05:57 	9.3M

firefox-3.0b4pre.en-US.win32.installer.exe	27-Feb-2008 05:41 	6.3M
firefox-3.0b4pre.en-US.win32.zip	27-Feb-2008 05:41 	8.8M

Not a huge download size win, but 200k in the installer and 500k in the zip, not bad!
Depends on: 419916
Product: Core → Firefox Build System
You need to log in before you can comment on or make changes to this bug.