415928 - fix packaging of CRT with jemalloc

Status: RESOLVED FIXED

(Firefox Build System :: General, defect)

Description

[(not currently active) Ted Mielczarek]

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).

Comment 1

[(not currently active) Ted Mielczarek]

Attachment: tinderbox config

Comment 2

[(not currently active) Ted Mielczarek]

Attachment: packaging patch

Comment 3

[(not currently active) Ted Mielczarek]

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.

Comment 4

[(not currently active) Ted Mielczarek]

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"

Comment 5

[(not currently active) Ted Mielczarek]

Attachment: fix CRT linkage [checked in]

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.

Comment 6

[(not currently active) Ted Mielczarek]

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.

Comment 7

[(not currently active) Ted Mielczarek]

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.

Comment 8

[(not currently active) Ted Mielczarek]

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.

Comment 9

[(not currently active) Ted Mielczarek]

Attachment: make nspr/nss play along

Ok, this is the final piece.

Comment 10

[Benjamin Smedberg]

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.

Comment 11

[Damon Sicore (:damons)]

Comment on attachment 301669 [details] [diff] [review]
packaging patch

a1.9+=damons

Comment 12

[Damon Sicore (:damons)]

Comment on attachment 304995 [details] [diff] [review]
make nspr/nss play along

a1.9+=damons

Comment 13

[(not currently active) Ted Mielczarek]

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.

Comment 14

[Reed Loden [:reed]]

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

Comment 15

[Dave Townsend [:mossop]]

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).

Comment 16

[(not currently active) Ted Mielczarek]

Ugh, it looks like NSS didn't take those changes.  Must have been something wrong in my tests.  I'll take another look.

Comment 17

[(not currently active) Ted Mielczarek]

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.

Comment 18

[(not currently active) Ted Mielczarek]

Attachment: make nspr/nss play along, v2

Ok, this actually works.

Comment 19

[Benjamin Smedberg]

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

Comment 20

[(not currently active) Ted Mielczarek]

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.  :-/

Comment 21

[(not currently active) Ted Mielczarek]

Attachment: make nspr/nss play along, v3 [checked in]

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.

Comment 22

[Damon Sicore (:damons)]

Comment on attachment 305557 [details] [diff] [review]
make nspr/nss play along, v3 [checked in]

a1.9+=damons

Comment 23

[(not currently active) Ted Mielczarek]

I'll check in the tinderbox config and packaging bits tomorrow in time for the nightly, since that will need a clobber.

Comment 24

[(not currently active) Ted Mielczarek]

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.

Comment 25

[:Gavin Sharp [email: [e-mail]]]

Attachment: bustage fix (checked in)

Worked this out with ted on IRC.

Comment 27

[(not currently active) Ted Mielczarek]

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!