209.95 KB, text/plain
536 bytes, patch
Benjamin Smedberg: approval1.8b4+
|Details | Diff | Splinter Review|
31.47 KB, text/plain
18.62 KB, text/plain
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: *** [mar.exe] Error 96 make: Leaving directory `/cygdrive/j/mozilla/mozilla/modules/libmar/tool' make: *** [libs] Error 2 make: Leaving directory `/cygdrive/j/mozilla/mozilla/modules/libmar' make: *** [tier_1] Error 2 make: Leaving directory `/cygdrive/j/mozilla/mozilla' make: *** [default] Error 2 make: 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.
Created attachment 188885 [details] Full build log from failed build 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
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:firstname.lastname@example.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?
Created attachment 189017 [details] [diff] [review] Set HOST_RANLIB 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
Created attachment 189019 [details] Different error after patch 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.
Created attachment 189120 [details] 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.
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
Last Resolved: 13 years ago
Resolution: --- → FIXED
Target Milestone: --- → Firefox1.1
You need to log in before you can comment on or make changes to this bug.