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

Status: RESOLVED WONTFIX

(SeaMonkey :: Build Config, defect)

Description

[Jens Hatlak (:InvisibleSmiley)]

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

Comment 1

[Jens Hatlak (:InvisibleSmiley)]

Attachment: .mozconfig

Comment 2

[Robert Kaiser]

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.

Comment 3

[Jens Hatlak (:InvisibleSmiley)]

Removing ac_add_options --disable-shared, as suggested on IRC, made no difference.

Comment 4

[Jens Hatlak (:InvisibleSmiley)]

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

Comment 5

[Robert Kaiser]

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

Comment 6

[Jens Hatlak (:InvisibleSmiley)]

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

Comment 7

[Robert Kaiser]

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

Comment 8

[Jens Hatlak (:InvisibleSmiley)]

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.

Comment 9

[timeless]

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

Comment 10

[Jens Hatlak (:InvisibleSmiley)]

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