Closed Bug 461342 Opened 16 years ago Closed 16 years ago

Icons corrupted/missing in seamonkey.exe

Categories

(Firefox Build System :: General, defect)

x86
OS/2
defect
Not set
normal

Tracking

(Not tracked)

RESOLVED FIXED

People

(Reporter: losepete, Assigned: mozilla)

Details

Attachments

(1 file)

User-Agent:       Mozilla/5.0 (OS/2; U; Warp 4.5; en-US; rv:1.9.1b2pre) Gecko/20081022 SeaMonkey/2.0a2pre
Build Identifier: Mozilla/5.0 (OS/2; U; Warp 4.5; en-US; rv:1.9.1b2pre) Gecko/20081022 SeaMonkey/2.0a2pre

Not a Windows system but there is the equivalent of a "Start" button.

When I looked at starting Seamonkey by working from that "Start" button the Seamonkey icons are corrupted; they display as multicoloured squares.

If I look at those program objects by opening the Seamonkey Desktop folder the icons display fine.

I then looked at the icons included as resources in the seamonkey executable and found only 1 icon - the 1 used in the Seamonkey Desktop folder - to be complete and look fine; the rest are either corrupt or totally black.

Having been informed that the seamonkey executable is compressed using lxlite I decmpressed the executable and then checked the icons. No problems; all icons display fine.

I then compressed the (decompressed) seamonke.exe file and rechecked the icons; only 1 is fine the rest are corrupt or black.

That seems to suggest that using lxlite causes the icons to become corrupt.

Reproducible: Always

Steps to Reproduce:
1. Install new copy of seamonkey V2

2. Check the icons in the seamonkey.exe: open the Properties for seamonkey.exe on the Icon page, click Edit to open the icon in the editor. Working in the editor click on Form name and then use the right arrow (->) on the keyboard to look at all icons involved. You will find most black, 1 corrupt and 1 that is fine

3. Use lxlite to decompress the seamonkey.exe file and then check the icons again; they should all be fine.
 
4. Re-compress using lxlte and check the icons again - back to only 1 icon OK
OK, thanks for filing this, Pete!

As discussed in mozilla.dev.ports.os2 we should change toolkit/mozapps/installer/os2/strip.cmd to not compress the main executable. To make it easier to do that for all apps and not just SeaMonkey, perhaps we should pass $(MOZ_PKG_APPNAME).exe to strip.cmd, too. STRIP_FLAGS in toolkit/mozapps/installer/packager.mk could perhaps be used for that.
Status: UNCONFIRMED → NEW
Component: General → Build Config
Ever confirmed: true
Product: SeaMonkey → Core
QA Contact: general → build-config
Version: unspecified → Trunk
Hah! I think it's even easier, we just need to add
 ! -name $(MOZ_PKG_APPNAME).exe
to PLATFORM_EXCLUDE_LIST.
Attached patch fixSplinter Review
This seems to work indeed to not compress the .exe file.

I thought about excluding static builds but then I discovered that the gains by running lxLite on thunderbird.exe are really small compared to a dynamic (or libxul) build (a few tens of kB vs a few hundred), so we can leave that uncompressed without too much of a drawback.
Assignee: nobody → mozilla
Status: NEW → ASSIGNED
Attachment #344598 - Flags: review?(wuno)
Comment on attachment 344598 [details] [diff] [review]
fix

 Directory of  E:\mozbuild1\mozilla\dist\bin\seamonkey.exe
26.10.08  18.19          24.180      22.524  seamonkey.exe

 Directory of  E:\mozbuild1\mozilla\dist\seamonkey\seamonkey.exe
26.10.08  18.19          24.180         124  seamonkey.exe
after running make package the size of the extended attributes still differs from the seamonkey.exe in the dist\bin directory (but why is the number in the bin directory such huge?)
Anyway, both files have equal size and the icon of the  seamonkey.exe excluded from compression with lxlite look nice on eCenter, where there were only colored stripes when the exe was compressed
Attachment #344598 - Flags: review?(wuno) → review+
Yes, there is an ICON EA attached to the exe before copying (apparently rc.exe not only embeds it into the exe but also attaches it as EA). But tar is used for copying and that apparently doesn't support EAs on OS/2. But these extra icons aren't needed for anything AFAIK, and it's not something that this change affected.

So, pushed:
http://hg.mozilla.org/mozilla-central/rev/00ae2c1a70ce


Pete, I will try to create a new nightly over the next days and then you can finally see the result of this long-running discussion.
Status: ASSIGNED → RESOLVED
Closed: 16 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.

Attachment

General

Created:
Updated:
Size: