Closed
Bug 160104
Opened 22 years ago
Closed 22 years ago
win32 gmake static builds busted
Categories
(SeaMonkey :: Build Config, defect, P2)
Tracking
(Not tracked)
VERIFIED
FIXED
mozilla1.2alpha
People
(Reporter: netscape, Assigned: netscape)
References
Details
Attachments
(1 file)
|
8.16 KB,
patch
|
bryner
:
review+
|
Details | Diff | Splinter Review |
I'm filing this on Cathleen's behalf. There was a tiny bit of bustage in the normal static build. Mostly forgetting to add MOZ_UNICHARUTIL_LIBS as necessary and one auto-vars issue in static-rules.mk When I attempted to build using --enable-meta-components=mail,crypto , I hit a bunch of problems with the creation of the mail meta component. Most of the problems stemmed from the differences in the library names on win32 from *every* other platform. How does mapi fit into the mail meta component? There appear to be 3 mapi libs that get built normally. msgMapi.dll is the xpcom component. Then there are mapiDll.dll & MapiProxy.dll which get installed into $(DIST)/bin . For now, I left the last two dlls out of the meta component and just build them as regular dlls in the static build. Cathleen, in your email, you mentioned other possible fringe static build cases that I have no idea how to reproduce even in the nmake build (ie, gecko.dll). Can you let me know what the targets for those cases should be so that we can implement them?
| Assignee | ||
Updated•22 years ago
|
| Assignee | ||
Comment 1•22 years ago
|
||
Comment 2•22 years ago
|
||
Comment on attachment 93291 [details] [diff] [review] patch v1 r=bryner
Attachment #93291 -
Flags: review+
| Assignee | ||
Comment 3•22 years ago
|
||
Patch has been checked in.
| Assignee | ||
Comment 4•22 years ago
|
||
Marking fixed. Reopen if there are other targets that need to be considered for the static win32 build.
Status: ASSIGNED → RESOLVED
Closed: 22 years ago
Resolution: --- → FIXED
Comment 5•22 years ago
|
||
I tried building the current trunk with ac_add_options --disable-shared ac_add_options --enable-static ac_add_options --disable-tests LINK : warning LNK4044: unrecognized option "L../../dist/lib/components"; ignore d gklayout.lib(nsSimplePageSequence.obj) : error LNK2005: "struct PRLogModuleInfo * kPrintingLogMod" (?kPrintingLogMod@@3PAUPRLogModuleInfo@@A) already defined i n gkgfxwin.lib(nsDeviceContextWin.obj) gklayout.lib(nsSimplePageSequence.obj) : warning LNK4006: "struct PRLogModuleInf o * kPrintingLogMod" (?kPrintingLogMod@@3PAUPRLogModuleInfo@@A) already defined in gkgfxwin.lib(nsDeviceContextWin.obj); second definition ignored Creating library mozilla.lib and object mozilla.exp mozilla.exe : fatal error LNK1169: one or more multiply defined symbols found make[3]: *** [mozilla.exe] Error 145 make[3]: Leaving directory `/cygdrive/c/statictrunk/mozilla/xpfe/bootstrap' make[2]: *** [libs] Error 2 Am I doing something wrong or is the static build still busted? Should this be reopened or would you like me to file another bug?
Comment 6•22 years ago
|
||
This is surely still busted. I got things to compile with this hack.
Index: nsDeviceContextSpecWin.cpp
===================================================================
RCS file: /cvsroot/mozilla/gfx/src/windows/nsDeviceContextSpecWin.cpp,v
retrieving revision 3.35
diff -u -r3.35 nsDeviceContextSpecWin.cpp
--- nsDeviceContextSpecWin.cpp 12 Jul 2002 11:48:36 -0000 3.35
+++ nsDeviceContextSpecWin.cpp 10 Aug 2002 15:22:55 -0000
@@ -61,8 +61,8 @@
#include "prlog.h"
#ifdef PR_LOGGING
-extern PRLogModuleInfo * kPrintingLogMod;
-#define PR_PL(_p1) PR_LOG(kPrintingLogMod, PR_LOG_DEBUG, _p1)
+extern PRLogModuleInfo * kPrintingLogModule;
+#define PR_PL(_p1) PR_LOG(kPrintingLogModule, PR_LOG_DEBUG, _p1)
#else
#define PR_PL(_p1)
#endif
Index: nsDeviceContextWin.cpp
===================================================================
RCS file: /cvsroot/mozilla/gfx/src/windows/nsDeviceContextWin.cpp,v
retrieving revision 3.99
diff -u -r3.99 nsDeviceContextWin.cpp
--- nsDeviceContextWin.cpp 12 Jul 2002 11:48:37 -0000 3.99
+++ nsDeviceContextWin.cpp 10 Aug 2002 15:22:56 -0000
@@ -60,8 +60,8 @@
#include "prlog.h"
#ifdef PR_LOGGING
-PRLogModuleInfo * kPrintingLogMod = PR_NewLogModule("printing");
-#define PR_PL(_p1) PR_LOG(kPrintingLogMod, PR_LOG_DEBUG, _p1)
+PRLogModuleInfo * kPrintingLogModule = PR_NewLogModule("printing");
+#define PR_PL(_p1) PR_LOG(kPrintingLogModule, PR_LOG_DEBUG, _p1)
#else
#define PR_PL(_p1)
#endif
But on startup I crash here.
NTDLL! 77fa018c()
nsToolkit::Init(nsToolkit * const 0x0219b830, PRThread * 0x01565038) line 358
NS_GetCurrentToolkit(nsIToolkit * * 0x02290c40) line 452
nsBaseWidget::BaseCreate(nsIWidget * 0x00000000, const nsRect & {...},
nsEventStatus (nsGUIEvent *)* 0x00cdb930
nsWebShellWindow::HandleEvent(nsGUIEvent *), nsIDeviceContext * 0x00000000,
nsIAppShell * 0x022a08e0, nsIToolkit * 0x00000000, nsWidgetInitData *
0x0012f578) line 162 + 12 bytes
nsWindow::StandardWindowCreate(nsIWidget * 0x00000000, const nsRect & {...},
nsEventStatus (nsGUIEvent *)* 0x00cdb930
nsWebShellWindow::HandleEvent(nsGUIEvent *), nsIDeviceContext * 0x00000000,
nsIAppShell * 0x022a08e0, nsIToolkit * 0x00000000, nsWidgetInitData *
0x0012f578, void * 0x00000000) line 1380
nsWindow::Create(nsWindow * const 0x02290c24, nsIWidget * 0x00000000, const
nsRect & {...}, nsEventStatus (nsGUIEvent *)* 0x00cdb930
nsWebShellWindow::HandleEvent(nsGUIEvent *), nsIDeviceContext * 0x00000000,
nsIAppShell * 0x022a08e0, nsIToolkit * 0x00000000, nsWidgetInitData *
0x0012f578) line 1543
nsWebShellWindow::Initialize(nsIXULWindow * 0x00000000, nsIAppShell *
0x022a08e0, nsIURI * 0x00000000, int 0x00000000, int 0x00000000, unsigned int
0x00000005, int 0x00000001, int 0x00000001, int 0x00000000, nsWidgetInitData &
{...}) line 300
nsAppShellService::JustCreateTopWindow(nsAppShellService * const 0x022a09a8,
nsIXULWindow * 0x00000000, nsIURI * 0x00000000, int 0x00000000, int 0x00000000,
unsigned int 0xf8000406, int 0x00000001, int 0x00000001, int 0x00000000,
nsIXULWindow * * 0x0012f648) line 715 + 56 bytes
nsAppShellService::CreateTopLevelWindow(nsAppShellService * const 0x022a09a8,
nsIXULWindow * 0x00000000, nsIURI * 0x00000000, int 0x00000000, int 0x00000000,
unsigned int 0xf8000406, int 0xffffffff, int 0xffffffff, nsIXULWindow * *
0x0012f648) line 588 + 46 bytes
nsWindowCreator::CreateChromeWindow(nsWindowCreator * const 0x02293538,
nsIWebBrowserChrome * 0x00000000, unsigned int 0xf8000406, nsIWebBrowserChrome *
* 0x0012f890) line 124 + 63 bytes
nsWindowWatcher::OpenWindowJS(nsWindowWatcher * const 0x022934e4, nsIDOMWindow *
0x00000000, const char * 0x0218c128, const char * 0x0131f56c, const char *
0x0131f0e8, int 0x00000001, unsigned int 0x00000001, long * 0x0219f188,
nsIDOMWindow * * 0x0012fad8) line 587 + 81 bytes
nsWindowWatcher::OpenWindow(nsWindowWatcher * const 0x022934e0, nsIDOMWindow *
0x00000000, const char * 0x0218c128, const char * 0x0131f56c, const char *
0x0131f0e8, nsISupports * 0x02117258, nsIDOMWindow * * 0x0012fad8) line 458 + 48
bytes
nsProfile::LoadDefaultProfileDir(nsCString & {...}, int 0x00000001) line 586 +
94 bytes
nsProfile::StartupWithArgs(nsProfile * const 0x0210b0a8, nsICmdLineService *
0x021554a8, int 0x00000001) line 414 + 16 bytes
nsAppShellService::DoProfileStartup(nsAppShellService * const 0x022a09a8,
nsICmdLineService * 0x021554a8, int 0x00000001) line 245 + 31 bytes
InitializeProfileService(nsICmdLineService * 0x021554a8) line 1172 + 31 bytes
main1(int 0x00000001, char * * 0x01567210, nsISupports * 0x00000000) line 1470 +
14 bytes
Just before crashing I see this warning
WARNING: dependent window created without a parent, file c:/statictrunk/mozilla
xpfe/bootstrap/nsWindowCreator.cpp, line 116
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
| Assignee | ||
Comment 7•22 years ago
|
||
This is a problem with the debug builds only. The optimized static build builds & launches fine. That's not the proper fix. There are 3 spots that kPrintingLogMod is being set. IIRC, the proper fix is to make the names unique. I'm willing to wager that this didn't work in the nmake builds either (the win32 static tinderbox was an opt build). Open a separate bug as that's definitely a code issue (that we don't hit in non-debug builds) and not an issue with the build framework.
Status: REOPENED → RESOLVED
Closed: 22 years ago → 22 years ago
Resolution: --- → FIXED
Comment 8•22 years ago
|
||
Yes, there is no way it could have worked with nmake either. Must have been broken since bug 121622 got fixed. Yes, I know that is may not be the right patch ... was just trying to get it compile. I'll open a new bug. Thanks.
Updated•20 years ago
|
Product: Browser → Seamonkey
You need to log in
before you can comment on or make changes to this bug.
Description
•