Closed Bug 600023 Opened 12 years ago Closed 12 years ago

gklayout.lib : fatal error LNK1106: invalid file or disk full: cannot seek to 0x... when building with /GL

Categories

(SeaMonkey :: Build Config, defect)

x86
Windows 7
defect
Not set
major

Tracking

(Not tracked)

RESOLVED WONTFIX

People

(Reporter: InvisibleSmiley, Unassigned)

Details

Attachments

(2 files)

Attached file output
Expanding on bug 598644 comment 5:

Roughly since the libxul switch was made on comm-central, I cannot build SM trunk on Windows anymore. Linux still works. I haven't made any changes to my build configuration (which worked until ~ a week ago), and always build from scratch (empty objdir). Building fails with both pymake and make -f client.mk build with the same output (please ignore the /LTCG stuff, that's normal).

Output attached, will attach .mozconfig ASAP.

Setup:
Win7 64-bit (building 32-bit)
MozillaBuild 1.5.1
MSVC 9 (VS 2008) Express
Win7 SDK + MS Platform SDK for Win Server 2003 R2

http://msdn.microsoft.com/en-us/library/dxd2zbyd.aspx says this is due to either a full disk, trying to link over the network, a bad block on disk or being out of head space. I can definitely eliminate the first two and the third is very unlikely since I can reproduce this 100%. I have no idea about the fourth.
Attached file .mozconfig
Time to clean up your mozconfig, then. ;-)

Base rule: Don't define anything where you don't have a good reason to override the defaults.

That means: Throw out all options except the --enable-application=suite and --disable-crashreporter ones, and clobber. If that still doesn't help, try disabling those strage flags one by one.
Removing ac_add_options --disable-shared, as suggested on IRC, made no difference.
Following KaiRo's advice I built with a minimal set of options now (see below) and succeeded. Will narrow it down further tomorrow.

mk_add_options MOZ_OBJDIR=/e/mozilla-src/seamonkey-central

# Parallelize building
mk_add_options MOZ_MAKE_FLAGS=-j

export MOZILLA_OFFICIAL=1
mk_add_options MOZILLA_OFFICIAL=1

ac_add_options --enable-application=suite
ac_add_options --disable-debug
ac_add_options --enable-strip
ac_add_options --disable-crashreporter
(In reply to comment #4)
> # Parallelize building
> mk_add_options MOZ_MAKE_FLAGS=-j

Without a number following it that is IIRC useless.

> export MOZILLA_OFFICIAL=1
> mk_add_options MOZILLA_OFFICIAL=1

Don't use that unless you are making an official release build. You don't need it.

> ac_add_options --disable-debug

That's default anyhow, just omit it.

> ac_add_options --enable-strip

Not sure if that one helps anything at all for you, but YMMV.
(In reply to comment #5)
> (In reply to comment #4)
> > # Parallelize building
> > mk_add_options MOZ_MAKE_FLAGS=-j
> 
> Without a number following it that is IIRC useless.

Wrong: Quoting from <http://www.gnu.org/software/make/manual/make.html#index-job-slots-342>:

"If the ‘-j’ option is followed by an integer, this is the number of recipes to execute at once; this is called the number of job slots. If there is nothing looking like an integer after the ‘-j’ option, there is no limit on the number of job slots."

Just what I want on my i7. :-)

In the meantime I found that the problem is located somewhere in my optimize/link options. Will continue checking later.
(In reply to comment #6)
> "If the ‘-j’ option is followed by an integer, this is the number of recipes to
> execute at once; this is called the number of job slots. If there is nothing
> looking like an integer after the ‘-j’ option, there is no limit on the number
> of job slots."

Ah, OK. We just know that we can run into awkward build race conditions with too high -j options on Windows, so not 100% sure if that's a good idea, but that's your choice. :)

> In the meantime I found that the problem is located somewhere in my
> optimize/link options. Will continue checking later.

I expected that much, actually, but cleaning up the rest by removing what's default anyhow is a good idea in any case. :)
Further investigation showed that it's /GL (Whole Program Optimization, part of my -GALFT in my --enable-optimize settings) which breaks my build:
http://msdn.microsoft.com/en/library/0zza0de8.aspx

I wonder whether this is related to bug 526038 (came there from http://forums.mozillazine.org/viewtopic.php?f=42&t=1708215 now). I have the workaround from comment 12 there applied locally so that I don't run into the crash at runtime. Haven't checked whether I'd crash with libxul, too, though.
whole program optimization has a tendency to fail. you should try to generate a bug report and send it to microsoft (there are instructions somewhere).

also consider using msvc10 instead (ms doesn't care much about older compilers...)
Summary: gklayout.lib : fatal error LNK1106: invalid file or disk full: cannot seek to 0x... → gklayout.lib : fatal error LNK1106: invalid file or disk full: cannot seek to 0x... when building with /GL
(In reply to comment #7)
> Ah, OK. We just know that we can run into awkward build race conditions with
> too high -j options on Windows, so not 100% sure if that's a good idea, but
> that's your choice. :)

Actually you were right. Building on Windows failed the other day (both make and pymake), and now that I had the time to check I found that it was due to unrestricted -j. Added back a 4 and now it's working again.

Anyway, it seems like the essence of this bug (the -GL issue) won't be fixed in Mozilla code and there is no point in having a bug around that only I ever confirmed. Thus marking WONTFIX.
Status: UNCONFIRMED → RESOLVED
Closed: 12 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.