Closed Bug 300123 Opened 19 years ago Closed 19 years ago

Visual Studio 2003 Build Failure Caused by mar.c

Categories

(Firefox Build System :: General, defect)

Product:
Firefox Build System
Component:
General
Platform:
x86
Windows XP
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
RESOLVED FIXED
Milestone:
Firefox1.5

People

(Reporter: bangbang023, Assigned: cls)

References

Details

Attachments

(4 files)

Full build log from failed build
209.95 KB, text/plain
Details
Set HOST_RANLIB
536 bytes, patch
cls
: review+
benjamin
: approval1.8b4+
Details | Diff | Splinter Review
Different error after patch
31.47 KB, text/plain
Details
fail with patch
18.62 KB, text/plain
Details 
User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b2) Gecko/20050705 Firefox/1.0+ (bangbang023)
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b2) Gecko/20050705 Firefox/1.0+ (bangbang023)

Staring with my morning build on July 6th, I have not been able to successfully
build Firefox using Visual Studio 2003. The error I get is as follows:

mar.c
/cygdrive/j/mozilla/mozilla/build/cygwin-wrapper /cygdrive/j/mozilla/mozilla/bui
ld/cygwin-wrapper cl -Fohost_mar.obj -c -TC -nologo -Fdhost_mar.pdb -DXP_WIN32 -
DXP_WIN -DWIN32 -D_WIN32 -DNO_X11 -O2 -GAL7 -arch:SSE2  -I../../../dist/include/
libmar -I../../../dist/include/mar -I../../../dist/include -I../../../dist/inclu
de/nspr    -I../../../dist/sdk/include -I../../../dist/include/nspr /cygdrive/j/
mozilla/mozilla/modules/libmar/tool/mar.c
mar.c
/cygdrive/j/mozilla/mozilla/build/cygwin-wrapper link -NOLOGO -OUT:mar.exe -PDB:
mar.pdb host_mar.obj  ../../../dist/host/lib/hostmar.lib ws2_32.lib
host_mar.obj : warning LNK4218: non-native module found; restarting link with /L
TCG
../../../dist/host/lib/hostmar.lib : warning LNK4003: invalid library format; li
brary ignored
../../../dist/host/lib/hostmar.lib : warning LNK4003: invalid library format; li
brary ignored
host_mar.obj : error LNK2001: unresolved external symbol _mar_create
host_mar.obj : error LNK2001: unresolved external symbol _mar_enum_items
host_mar.obj : error LNK2001: unresolved external symbol _mar_extract
host_mar.obj : error LNK2001: unresolved external symbol _mar_open
host_mar.obj : error LNK2001: unresolved external symbol _mar_close
mar.exe : fatal error LNK1120: 5 unresolved externals
make[4]: *** [mar.exe] Error 96
make[4]: Leaving directory `/cygdrive/j/mozilla/mozilla/modules/libmar/tool'
make[3]: *** [libs] Error 2
make[3]: Leaving directory `/cygdrive/j/mozilla/mozilla/modules/libmar'
make[2]: *** [tier_1] Error 2
make[2]: Leaving directory `/cygdrive/j/mozilla/mozilla'
make[1]: *** [default] Error 2
make[1]: Leaving directory `/cygdrive/j/mozilla/mozilla'
make: *** [build] Error 2 

Reproducible: Always

Steps to Reproduce:
1.Attempt to build Firefox using VS 2003

Actual Results:  
Received error above

Expected Results:  
Successfully compiled as it did on July 5th and before. 

I have already tried nuking my tree and still get the same error.
Regression of bug 299557 ?
I believe it is indeed a regression from that patch since that patch was checked
in after my last successful build. 

To verify it's not my system, I nuked my tree and used a .mozconfig from
bluefyre (he's been building successfully in vs 2003) and I still received the
same error. 
Can you provide a full from scratch build log?  That error only shows that link
thinks hostmar.lib is invalid.

Here is the full build log which you requested.
According to the log, every library that was created with 'lib' is throwing that
'non-native module found' warning.  I don't think this problem was caused by bug
299557 as the linking of the target mar.lib & the nspr libs (which weren't
touched by bug 299557) are throwing the same error.  Are you using the lib.exe
from VS2003?

According to my mozconfig I should be:

. $topsrcdir/browser/config/mozconfig

GLIB_PREFIX=J:/mozilla/w32build/vc7
LIBIDL_PREFIX=J:/mozilla/w32build/vc7

export MOZ_PHOENIX=1
export MOZ_OPTIMIZE_LDFLAGS="-opt:ref,icf,nowin98"

mk_add_options MOZ_PHOENIX=1
mk_add_options MOZ_OPTIMIZE_LDFLAGS="-opt:ref,icf,nowin98"

ac_add_options --enable-static
ac_add_options --enable-svg
ac_add_options --enable-canvas
ac_add_options --enable-strip
ac_add_options --enable-single-profile
ac_add_options --enable-optimize="-O2 -GAL7 -arch:SSE2"
ac_add_options
--enable-extensions=cookie,xml-rpc,xmlextras,pref,transformiix,universalchardet,webservices,inspector,negotiateauth,reporter

ac_add_options --disable-activex
ac_add_options --disable-activex-scripting
ac_add_options --disable-tests
ac_add_options --disable-debug
ac_add_options --disable-mailnews
ac_add_options --disable-composer
ac_add_options --disable-ldap
ac_add_options --disable-profilesharing
ac_add_options --disable-shared
ac_add_options --disable-accessibility
ac_add_options --disable-installer

No dupes found. Marking NEW.
Status: UNCONFIRMED → NEW
Depends on: 299557
Ever confirmed: true
That mozconfig doesn't say anything about the VS paths being used.  I built with
the free MSVC last night and it built mar.exe without a problem.

Alex, since when does "no dupes filed" mean "confirmed"?  Can you actually
reproduce the problem?
No longer depends on: 299557
(In reply to comment #8)
> Alex, since when does "no dupes filed" mean "confirmed"?  Can you actually
> reproduce the problem?

Hi Chris, I didn't mean to imply that I had personally confirmed the bug.
However, Christopher/bangbang is an experienced developer and I trust his
judgement on the nature of the bug; however, I still checked for dupes since
those can sometimes slip by.

Didn't mean to step on your toes, Chris.
> Alex, since when does "no dupes filed" mean "confirmed"? 

wasn't that always the case? http://www.mozilla.org/quality/help/unconfirmed.html
(In reply to comment #10)
> > Alex, since when does "no dupes filed" mean "confirmed"? 
> 
> wasn't that always the case? http://www.mozilla.org/quality/help/unconfirmed.html

Ugh.  I thought we fixed that broken assumption a long time ago.  Why even
bother with the unconfirmed state then.  Sorry, Alex, my mistake.

Ok, so it isn't pointing directly to the lib.exe, but it NEVER has in the past
and all compilations were successful for over a year. What's changed in config
requirements, then, that would require a direct linking to the lib.exe located
in the VS install directory?


my current and never changes mozset

@echo off
set MOZ_TOOLS=J:\mozilla\moztools
set GLIB_PREFIX=J:\mozilla\w32build\vc7
set LIBIDL_PREFIX=J:\mozilla\w32build\vc7
set MOZ_SRC=J:\mozilla
call c:\"program files"\"microsoft visual studio .net
2003"\common7\tools\vsvars32.bat
set
PATH=%PATH%;j:\mozilla\cygwin\bin;%GLIB_PREFIX%\bin;%LIBIDL_PREFIX%\bin;%MOZ_TOOLS%\bin
set HOME=J:\mozilla
set CVSROOT=:pserver:anonymous@cvs-mirror.mozilla.org:/cvsroot
Sorry for so many consecutive updates, but it's definitely not an issue caused
by a missing lib.exe. After running my mozset, I can access lib from the command
prompt simply by entering "lib" as the command meaning the paths ARE configured
properly and the build would have complete access to the executable. 
I never said that lib.exe was missing.  I asked if you were using the correct
version.  The updater code is relatively new for starters.  Even without my
changes, the updater Makefiles will still create a static library using lib.exe
and link against that library.  

According to the build log, every static library being built in your tree is
throwing that warning message.  So even if you disable the updater code (via
--disable-updater), I'm pretty sure that you're still going to hit this problem
elsewhere.  Afaict, mar.exe just happens to be the first place in the tree that
we link against a Mozilla-built static library (vs import library).

> lib -NOLOGO -OUT:"jpeg3250.lib" ....
>  jcprepct.obj : warning LNK4218: non-native module found; restarting link with
/LTCG

For whatever reason, lib.exe does not like the format of some of the compiled
files.  Have you tried a build with the stock optimization flags? 

lib.exe version is 7.10.3077.

I just tried a build with disable-updater added to my mozconfig and it compiled
succesfully. Something has to be up with the updater code. My ONLY idea is that
maybe there's a call for precompiled headers in there just like the one I remove
in cvsroot\mozilla\js\src\xpconnect\src\Makefile.in.
Interesting. The libmar code is fairly small and I didn't see any precompiled
header directives in the Makefiles.  Maybe darin knows of any issues with
precompiled headers?

Can you reproduce the original error with the default build optimizations and
without --disable-updater?

Let me know what the default opts are and I will give it a whirl. I have a
little time tonight and tomorrow night so I can keep at it for you guys. For
now, I'm just going to release daily builds with the updater disabled. 
(In reply to comment #18)
> Let me know what the default opts are and I will give it a whirl.

just use --enable-optimize without any =".." stuff
I use VS.NET 2003, and I don't have any trouble compiling mar.c

There's no explicit use of precompiled headers in libmar.
Same errors with the default optimize command
Darin: what version of lib do you have on your system?

Also, this updater wouldn't need something like activeperl installed would it? 
Ok, I think I found the problem:

> ranlib hostmar.lib
> echo not_ranlib mar.lib

HOST_RANLIB is set incorrectly and whatever cygwin's ranlib does to the .lib,
at least one variant of VS2003 doesn't like it.  

Darin, out of curiosity, is HOST_RANLIB set to 'ranlib' or ':' on your system?
Assignee: nobody → cls
Status: NEW → ASSIGNED
Attachment #189017 - Flags: review?(bangbang023)
Depends on: 299557
The patch gives me this error now. 

However, this DID fix it and it compiled successfully when testing:
http://forums.mozillazine.org/viewtopic.php?p=1598200#1598200
Damn, the error wasn't sent to the log and I need to get some sleep. However, it
was something about tier 2 or level 2. Sorry, if I could I would do it again to
get the error, but I need sleep now. 

HOST_RANLIB = :
I want to clarify a previous statement. I atcually get the same error even when
using the patch posted above. So far, only ozone's suggestion has worked.
I give up. Maybe i'm trying too hard, but ozone's suggestion doesn't work at
all. I think, last night, in my sleepiness, I accidentally mistook a successful
build with the updater disabled as one with it actually enabled.

To sum up, nothing has fixed this issue. 
Have you cleaned the <obj-dir>\modules\libmar\src and
<obj-dir>\modules\libmar\tools dirs? Delete the .lib files and to be safe the
.obj files.
Ok, I did further testing and took my time this time around. On a fully cleaned
tree, ozone's solution DOES work. On a competely clean tree, the patch above
DOES NOT work. I'm sorry for the confusion. I've been rushing myself and it
wasn't to anyone's best interest. So, yes, ozone's fix does work 100%. The patch
does not.
Attached file fail with patch — 
The patch gives me the following output. I did not log the whole build, but
this is everything from the command window.
Afaict, you're hitting a separate problem there since it's dying in modules/zlib
& not even reaching the updater code.   It looks like modules/zlib/Makefile
wasn't generated.  

And don't forget to run autoconf after applying the patch to configure.in. 

autoconf? I did not know about this. Simply run the command by itself or what?
Any changes to configure.in require you to run autoconf (2.13) to regenerate
configure.  I generally don't make patches against configure because it's a
generated file and the patches often conflict since the slightest change in
configure.in causes a huge change in configure.

Cygwin comes with autoconf wrappers which usually pick the correct version of
autoconf so you can just run 'autoconf'.

autoconf comes up as an unrecognized command.

Next time, I'll make sure I'm inside bash :shame: I'll try it again and get back
to you. 
The patch worked. Thank you. I'm hoping now that it can be landed as long as it
doesn't break anything for people who did not have this issue.

Side question: running a make clean won't undo what autconf did right? My batch
file runs a make clean and I need to know if I'll run into issues with that or not. 
Comment on attachment 189017 [details] [diff] [review]
Set HOST_RANLIB 

To undo the change, you'd have to remove configure & cvs update or unapply the
patch & re-run autoconf.  A simple `make clean` or even `make distclean` will
not affect it.
Attachment #189017 - Flags: review?(bangbang023)
Attachment #189017 - Flags: review+
Attachment #189017 - Flags: approval1.8b4?
Thank you for your help man. The level of building/patching we had to go into
was something I was a little untested in and I'm sure I got annoying at times,
so thanks for sticking it out. I'm just glad I can start pumping out daily
builds again.
Attachment #189017 - Flags: approval1.8b4? → approval1.8b4+
No need to thank me.  I'm a firm believer in "You broke it; you fix it".  Sorry
about the trouble.  The patch has been checked in.
Status: ASSIGNED → RESOLVED
Closed: 19 years ago
Resolution: --- → FIXED
Target Milestone: --- → Firefox1.1
Component: Build Config → General
Product: Firefox → Firefox Build System
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: