Closed Bug 415661 Opened 14 years ago Closed 14 years ago

[OS/2] move stripping (-s) of exe and dll files to MOZ_OPTIMIZE_LDFLAGS


(Firefox Build System :: General, defect)

Not set


(Not tracked)



(Reporter: wuno, Assigned: wuno)



(2 files)

User-Agent:       Mozilla/5.0 (OS/2; U; Warp 4.5; en-US; rv:1.9b3pre) Gecko/2008020120 Minefield/3.0b3pre
Build Identifier: 

See bug201555. We can't use the strip.exe on OS/2, thus we strip at compile time (MOZ_OPTIMIZE_CFLAGS="O2 -s". The build system has changed a bit in the last months, several modules are optimized separately (mozjs.dll, sqlite3.dll). We profit from these optimizations as they are implemented like ifdef GNU_CC. Usually these optimizations change the -Ox flag to something optimal for this module. As most GCC builds strip after completion of the build (--enable-strip) they don't need to strip during compilation. Thus, on OS/2 we lose the stripping of (for optimized builds useless) Debug symbols for these modules.

Reproducible: Always

Steps to Reproduce:
Actual Results:  
We would have the possibility to patch the Makefiles of the respective modules. But we would then have to watch them carefully. Adding SET CFLAGS=-s to setmozenv.cmd would work too, but one has to remember to unset it for a debug build.

Expected Results:  
Remembering that I added some time ago '-s' not to CFLAGS but to LDFLAGS on linux, I tried if it would work also on OS/2 and it does, dll and exe. The linker flag '-s' is passed to GCC during the final link of dll and exe files. I'd think putting this to LDFLAGS that don't usually are changed for modules would be the best solution.
Same tree and objdir (removed completely between builds). Dir listing of a Seamonkey main dist\bin
On top always the size of usual MOZ_OPTIMIZE_CFLAGS="-O2 -s", below MOZ_OPTIMIZE_CFLAGS="-O2" and MOZ_OPTIMIZE_LDFLAGS="-s ....". All not module-optimized files are of the same size, mozjs.dll and sqlite3.dll are smaller in the second build, cause they are stripped. (No changes observed in the subdirs)
Attached patch trivial movementSplinter Review
Looking at the dir output this saves us not very much bytes compared to the whole SM build, but the main purpose would be to not have to take care if further modules are optimized (without getting stripped on OS/2)
Attachment #301388 - Flags: review?(mozilla)
Yes, I'm sure this works. But can you try timing to compile and link in layout/build? I would like to use the method that's faster there because that takes fairly long and is _the_ annoyance to me during development. Or, if that's easier, link a static firefox.exe or libxul.dll.

I actually wanted to fix the problem by adding lxlite back in to the packaging process as it has been on the 1.8 branch (see That would help the sizes even more than the strip that GCC can do.
Ever confirmed: true
Hardware: Other → PC
Version: unspecified → Trunk
calculated from nspr4.dll to firefox.exe
build times seamonkey:
-O2 -s 60 min | -O2; -s 66 min
firefox (libxul):
-O2 -s 56 min | -O2; -s 53 min
from sqlite3.dll to platform.ini (all in gfx,layout...)
-02 -s 37 min | -O2; -s 35 min
Then I tried as on linux (would save another ~600 kb uncompressed):
-Os -freorder-blocks -fno-reorder-functions -s 53 min | -Os -freorder-blocks -fno-reorder-functions; -s 56 min
Platform AthlonXP5000 DualCore (only 1 Processor, SMP does not work)
ac_add_options --enable-application=browser
ac_add_options --enable-optimize
ac_add_options --enable-os2-high-mem
ac_add_options --disable-debug
ac_add_options --disable-tests
I'm not sure, if the +/- 3 min really depend on the build configuration or are some kind of SD. To figure this out I'd have to build more often.
I found another build, where I patched all Makefiles with MOZ_MODULE_OPTIMIZE to strip during build time and nss alike bug389781, total build time for this firefox 51 min.
Comment on attachment 301388 [details] [diff] [review]
trivial movement

Don't really understand which number relates to which option (I don't think you actually used a ';' in the flags).

But as there isn't a big difference in build times one way or the other and I just tested that the .lib files without -s are only marginally bigger, I'm happy with this suggestion.
Attachment #301388 - Flags: review?(mozilla) → review+
Assignee: nobody → wuno
Patch checked into trunk.
Closed: 14 years ago
Resolution: --- → FIXED
Product: Core → Firefox Build System
You need to log in before you can comment on or make changes to this bug.