This is a general bug about work I am doing to make mozilla buildable using GCC in win32 (using the cygwin GCC and using the mingw32 header files and libraries where needed) I will post any patches that I come up with in this bug. If anyone wants to help, let me know. In particular, I need someone to help me make sure that I folow the "rules" and that my changes dont break anything else (such as builds on other platforms, which I cant test on since I dont even have a mac or linux box) I have done some work in the past in getting stuff written for visual C++ working on gcc so I know some of the things involved.

I have finally gotten a full source tree and am examining the build process. To me, the easiest way to implement any build process changes is not to change the build configs but instead to write "stubs" for the MS tools, i.e. write a program called cl.exe that translates microsoft compiler arguments to gcc compiler arguments. Same for link.exe and so on. Then, once thats done, you can put those into the path somewhere (and configure include/lib etc) and see what happens when you build.

interestingly this is not a duplicate confirming

oh, btw, bug 62773 is related

marking helpwanted so I can get someone to help me with some of the confusing stuff in the mozilla configure scripts (I know how to read a configure script but I cant folow mozillas scripts)

Finally getting somewhere with this, still need some help from someone that knows the NSPR build scripts to get that part working though. I sorta know what changes to make but I cant figure out where to make them.

Jonathan, NSPR also uses a configure script, but it is seperate from Mozilla's. It's in nsprpub/configure, generated from nsprpub/configure.in. The configure script generates the Makefiles from Makefile.in in each directory.

I am aware of the fact that NSPR has its own configure script. Dont expect any work on this for a few days, I am having computer problems with my main development box :(

If you have any questions on what this does, what it changes etc, I will be happy to answer them. Note that when building this, set CC=gcc and CXX=g++. Should work with cygwin or moztools uname. Also set moz_tools and path as usual. Feedback on how I have done things etc appreciated... Have I done something in a way that breaks other platforms or something? if so, tell me. Anything at all thats wrong with it, tell me now. This patch is against whatever version of NSPR is pulled by client.mk when pulling seamonkeyall. Currently, it starts building then spits out an error about nsinstall not being where it should be. There is a nsinstall.c file in the right place, its just not making a nsinstall.exe file for some reason, anyone know what to do to get it fixed (so I can then continue with the build)

more info on the nsinstall problem... Acording to config/makefile.in (and also therefore config/makefile) ifneq ($(OS_ARCH),OS2) CSRCS += nsinstall.c OS_ARCH isnt OS2, its windows. Yet nsinstall.c doesnt seem to be being added to CSRCS properly. Either that or its being added to CSRCS but not being built. Any ideas?

Add something like showval: @echo $(CSRCS) to config/Makefile, cd into config and run "gmake showval". If nsinstall.c shows up in the output, try "gmake nsinstall.exe". That might provide a clue as to why it's not being built.

Code now compiles to w95cv.c, anyone want to help me figure out what to do to fix that file? Note that this replaces the earlier patch

What's the error output at the w95cv.c break?

gcc -o w95cv.o -c -mno-cygwin -g -UNDEBUG -DMOZILLA_CLIENT=1 -DDEBUG=1 -D DEBUG_Jonathan=Wilson\ 1 -DXP_PC=1 -DWIN32=1 -DNONAMELESSUNION=1 -DWIN95=1 -D_PR _GLOBAL_THREADS_ONLY=1 -D_X86_=1 -DHAVE_STRERROR=1 -DFORCE_PR_LOG -D_NSPR_BUILD _ -Ic:/mozilla/dist/include/nspr -I../../../../pr/include -I../../../../pr/inclu de/private w95cv.c In file included from w95cv.c:49: ../../../../pr/include/private/primpl.h:347: warning: `_MD_GET_INTSOFF' redefine d c:/mozilla/dist/include/nspr/md/_winnt.h:513: warning: this is the location of t he previous definition ../../../../pr/include/private/primpl.h:348: warning: `_MD_SET_INTSOFF' redefine d c:/mozilla/dist/include/nspr/md/_winnt.h:522: warning: this is the location of t he previous definition In file included from /usr/include/w32api/windows.h:154, from c:/mozilla/dist/include/nspr/md/_winnt.h:48, from c:/mozilla/dist/include/nspr/md/prosdep.h:49, from ../../../../pr/include/private/primpl.h:75, from w95cv.c:49: /usr/include/w32api/winsock2.h:662: warning: redefinition of `int32' c:/mozilla/dist/include/nspr/obsolete/protypes.h:156: warning: `int32' previousl y declared here In file included from c:/mozilla/dist/include/nspr/md/prosdep.h:49, from ../../../../pr/include/private/primpl.h:75, from w95cv.c:49: c:/mozilla/dist/include/nspr/md/_winnt.h:458: warning: `thread' attribute direct ive ignored c:/mozilla/dist/include/nspr/md/_winnt.h:476: warning: `thread' attribute direct ive ignored c:/mozilla/dist/include/nspr/md/_winnt.h:492: warning: `thread' attribute direct ive ignored c:/mozilla/dist/include/nspr/md/_winnt.h:508: warning: `thread' attribute direct ive ignored w95cv.c: In function `AddThreadToCVWaitQueueInternal': w95cv.c:61: structure has no member named `waitTail' w95cv.c:61: structure has no member named `waitHead' w95cv.c:62: structure has no member named `waitTail' w95cv.c:62: structure has no member named `waitHead' w95cv.c:63: structure has no member named `nwait' w95cv.c:64: structure has no member named `inCVWaitQueue' w95cv.c:65: structure has no member named `next' w95cv.c:66: structure has no member named `prev' w95cv.c:66: structure has no member named `waitTail' w95cv.c:67: structure has no member named `waitHead' w95cv.c:68: structure has no member named `waitHead' w95cv.c:70: structure has no member named `waitTail' w95cv.c:72: structure has no member named `waitTail' w95cv.c: In function `md_UnlockAndPostNotifies': w95cv.c:92: `_MDNotified' undeclared (first use in this function) w95cv.c:92: (Each undeclared identifier is reported only once w95cv.c:92: for each function it appears in.) w95cv.c:92: parse error before `post' w95cv.c:93: `notified' undeclared (first use in this function) w95cv.c:93: `prev' undeclared (first use in this function) w95cv.c:101: `post' undeclared (first use in this function) w95cv.c:101: structure has no member named `notified' w95cv.c:104: structure has no member named `notified' w95cv.c:121: structure has no member named `waitHead' w95cv.c:129: structure has no member named `waitHead' w95cv.c:131: structure has no member named `inCVWaitQueue' w95cv.c:132: structure has no member named `next' w95cv.c:134: structure has no member named `waitHead' w95cv.c:135: structure has no member named `waitHead' w95cv.c:135: structure has no member named `waitTail' w95cv.c:136: structure has no member named `nwait' w95cv.c:138: structure has no member named `waitHead' w95cv.c:141: structure has no member named `inCVWaitQueue' w95cv.c:142: structure has no member named `next' w95cv.c:145: structure has no member named `waitHead' w95cv.c:146: structure has no member named `waitHead' w95cv.c:147: structure has no member named `waitHead' w95cv.c:148: structure has no member named `waitTail' w95cv.c:150: structure has no member named `waitHead' w95cv.c:151: structure has no member named `waitHead' w95cv.c:152: structure has no member named `waitHead' w95cv.c:155: structure has no member named `nwait' w95cv.c:178: structure has no member named `next' w95cv.c:179: structure has no member named `prev' w95cv.c:179: structure has no member named `next' w95cv.c: In function `md_PostNotifyToCvar': w95cv.c:201: `_MDNotified' undeclared (first use in this function) w95cv.c:201: `notified' undeclared (first use in this function) w95cv.c:201: structure has no member named `notified' w95cv.c:215: `_MD_CV_NOTIFIED_LENGTH' undeclared (first use in this function) w95cv.c:219: parse error before `)' w95cv.c: In function `_MD_NEW_CV': w95cv.c:242: structure has no member named `magic' w95cv.c:242: `_MD_MAGIC_CV' undeclared (first use in this function) w95cv.c: In function `_MD_FREE_CV': w95cv.c:252: structure has no member named `magic' w95cv.c: In function `_MD_WAIT_CV': w95cv.c:269: structure has no member named `notified' w95cv.c:283: structure has no member named `inCVWaitQueue' w95cv.c:286: structure has no member named `inCVWaitQueue' w95cv.c:287: structure has no member named `waitTail' w95cv.c:287: structure has no member named `waitHead' w95cv.c:288: structure has no member named `waitTail' w95cv.c:288: structure has no member named `waitHead' w95cv.c:289: structure has no member named `nwait' w95cv.c:290: structure has no member named `inCVWaitQueue' w95cv.c:291: structure has no member named `waitHead' w95cv.c:292: structure has no member named `waitHead' w95cv.c:292: structure has no member named `next' w95cv.c:293: structure has no member named `waitHead' w95cv.c:294: structure has no member named `waitTail' w95cv.c:296: structure has no member named `waitHead' w95cv.c:299: structure has no member named `prev' w95cv.c:300: structure has no member named `prev' w95cv.c:300: structure has no member named `next' w95cv.c:301: structure has no member named `next' w95cv.c:302: structure has no member named `next' w95cv.c:302: structure has no member named `prev' w95cv.c:304: structure has no member named `waitTail' w95cv.c:305: structure has no member named `waitTail' w95cv.c:305: structure has no member named `prev' w95cv.c:308: structure has no member named `next' w95cv.c:308: structure has no member named `prev' w95cv.c:320: structure has no member named `inCVWaitQueue' w95cv.c: At top level: w95cv.c:336: parse error before `&' Thats all the output from GCC There are also a number of warnings (both with this file and others), I dont know if they are important to fix or not...

Comment on attachment 79040 [details] [diff] [review] patch v2 Don't include configure diffs in your patches. It contains generated line numbers at key points which means that anything other than the smallest change will generate a relatively huge and redundant patch. In nsprpub/config/Makefile.in & rules.mk, the checks should be using NS_USE_GCC instead of directly comparing $CC & gcc. In configure.in, you should test that the output of $CC/$CXX -V contains gcc and set GNU_CC/GNU_CXX as appropriate. It's possible that whomever's calling the script may give the full path to the compiler. The change to now.c seems wrong. It should actually do something for the mingw case. Does the compile there fail because gcc doesn't know about __int64 or doesn't have ftime()?

Thanks for the tip about configure difs. Is there a way to tell cvs diff -u nsprpub not to diff configure? ok, thanks for the info about NS_USE_GCC, how should I use NS_USE_GCC? what code should I use to set GNU_CC/GNU_CXX? As for now.c, cygwin GCC doesnt seem to like something in there since it gives references to an undefined external on linking. I cant find that external in any libraries anywhere.

wrt the w95cv.c errors, it looks as though |struct _MDCVar| is being improperly defined. Make sure that MDCPUCFG_H is being properly defined in config/autoconf.mk. I noticed that there are some places in the code that check for the _WIN32 define which isn't set by the build system so must be set by MSVC. You could try adding that define to your build.

More info on the cc=path_to_gcc stuff. It works fine if you pass a cygwin path like /bin/gcc or /cygdrive/c/gcc/bin/gcc If you pass a msdos path like c:\cygwin\bin\gcc it fails, probobly because the various commands being used in configure.in are built to work with cygwin paths only. Any suggestions on how to fix this will be appreciated but for now, I will leave it as is (since I dont know the fix)

with regard to MDCPUCFG_H, its being set to _win95.cfg like it should be. As for _WIN32, I added code to _win95.cfg as folows #ifndef _WIN32 #define _WIN32 #endif Setting _WIN32 seems to get w95cv.c to compile. Thanks for the info. Now it spits out some other errors but I cant fix those untill I can find out from someone the right way to say if we are using gcc then do xyz else do abc endif

Here is the current output from GCC for w95cv.c /bin/gcc -o w95cv.o -c -mno-cygwin -g -UNDEBUG -DDEBUG=1 -DDEBUG_Jonathan =Wilson\ 1 -DXP_PC=1 -DWIN32=1 -DNONAMELESSUNION=1 -DWIN95=1 -D_PR_GLOBAL_THREAD S_ONLY=1 -D_X86_=1 -DHAVE_STRERROR=1 -DFORCE_PR_LOG -D_NSPR_BUILD_ -I../../../. ./dist/include/nspr -I../../../../pr/include -I../../../../pr/include/private w 95cv.c In file included from w95cv.c:49: ../../../../pr/include/private/primpl.h:347: warning: `_MD_GET_INTSOFF' redefine d ../../../../dist/include/nspr/md/_winnt.h:513: warning: this is the location of the previous definition ../../../../pr/include/private/primpl.h:348: warning: `_MD_SET_INTSOFF' redefine d ../../../../dist/include/nspr/md/_winnt.h:522: warning: this is the location of the previous definition In file included from /usr/include/w32api/windows.h:154, from ../../../../dist/include/nspr/md/_winnt.h:48, from ../../../../dist/include/nspr/md/prosdep.h:49, from ../../../../pr/include/private/primpl.h:75, from w95cv.c:49: /usr/include/w32api/winsock2.h:662: warning: redefinition of `int32' ../../../../dist/include/nspr/obsolete/protypes.h:156: warning: `int32' previous ly declared here In file included from ../../../../dist/include/nspr/md/prosdep.h:49, from ../../../../pr/include/private/primpl.h:75, from w95cv.c:49: ../../../../dist/include/nspr/md/_winnt.h:458: warning: `thread' attribute direc tive ignored ../../../../dist/include/nspr/md/_winnt.h:476: warning: `thread' attribute direc tive ignored ../../../../dist/include/nspr/md/_winnt.h:492: warning: `thread' attribute direc tive ignored ../../../../dist/include/nspr/md/_winnt.h:508: warning: `thread' attribute direc tive ignored w95cv.c: In function `AddThreadToCVWaitQueueInternal': w95cv.c:64: structure has no member named `waitTail' w95cv.c:64: structure has no member named `waitHead' w95cv.c:65: structure has no member named `waitTail' w95cv.c:65: structure has no member named `waitHead' w95cv.c:66: structure has no member named `nwait' w95cv.c:67: structure has no member named `inCVWaitQueue' w95cv.c:68: structure has no member named `next' w95cv.c:69: structure has no member named `prev' w95cv.c:69: structure has no member named `waitTail' w95cv.c:70: structure has no member named `waitHead' w95cv.c:71: structure has no member named `waitHead' w95cv.c:73: structure has no member named `waitTail' w95cv.c:75: structure has no member named `waitTail' w95cv.c: In function `md_UnlockAndPostNotifies': w95cv.c:95: `_MDNotified' undeclared (first use in this function) w95cv.c:95: (Each undeclared identifier is reported only once w95cv.c:95: for each function it appears in.) w95cv.c:95: parse error before `post' w95cv.c:96: `notified' undeclared (first use in this function) w95cv.c:96: `prev' undeclared (first use in this function) w95cv.c:104: `post' undeclared (first use in this function) w95cv.c:104: structure has no member named `notified' w95cv.c:107: structure has no member named `notified' w95cv.c:124: structure has no member named `waitHead' w95cv.c:132: structure has no member named `waitHead' w95cv.c:134: structure has no member named `inCVWaitQueue' w95cv.c:135: structure has no member named `next' w95cv.c:137: structure has no member named `waitHead' w95cv.c:138: structure has no member named `waitHead' w95cv.c:138: structure has no member named `waitTail' w95cv.c:139: structure has no member named `nwait' w95cv.c:141: structure has no member named `waitHead' w95cv.c:144: structure has no member named `inCVWaitQueue' w95cv.c:145: structure has no member named `next' w95cv.c:148: structure has no member named `waitHead' w95cv.c:149: structure has no member named `waitHead' w95cv.c:150: structure has no member named `waitHead' w95cv.c:151: structure has no member named `waitTail' w95cv.c:153: structure has no member named `waitHead' w95cv.c:154: structure has no member named `waitHead' w95cv.c:155: structure has no member named `waitHead' w95cv.c:158: structure has no member named `nwait' w95cv.c:181: structure has no member named `next' w95cv.c:182: structure has no member named `prev' w95cv.c:182: structure has no member named `next' w95cv.c: In function `md_PostNotifyToCvar': w95cv.c:204: `_MDNotified' undeclared (first use in this function) w95cv.c:204: `notified' undeclared (first use in this function) w95cv.c:204: structure has no member named `notified' w95cv.c:218: `_MD_CV_NOTIFIED_LENGTH' undeclared (first use in this function) w95cv.c:222: parse error before `)' w95cv.c: In function `_MD_NEW_CV': w95cv.c:245: structure has no member named `magic' w95cv.c:245: `_MD_MAGIC_CV' undeclared (first use in this function) w95cv.c: In function `_MD_FREE_CV': w95cv.c:255: structure has no member named `magic' w95cv.c: In function `_MD_WAIT_CV': w95cv.c:272: structure has no member named `notified' w95cv.c:286: structure has no member named `inCVWaitQueue' w95cv.c:289: structure has no member named `inCVWaitQueue' w95cv.c:290: structure has no member named `waitTail' w95cv.c:290: structure has no member named `waitHead' w95cv.c:291: structure has no member named `waitTail' w95cv.c:291: structure has no member named `waitHead' w95cv.c:292: structure has no member named `nwait' w95cv.c:293: structure has no member named `inCVWaitQueue' w95cv.c:294: structure has no member named `waitHead' w95cv.c:295: structure has no member named `waitHead' w95cv.c:295: structure has no member named `next' w95cv.c:296: structure has no member named `waitHead' w95cv.c:297: structure has no member named `waitTail' w95cv.c:299: structure has no member named `waitHead' w95cv.c:302: structure has no member named `prev' w95cv.c:303: structure has no member named `prev' w95cv.c:303: structure has no member named `next' w95cv.c:304: structure has no member named `next' w95cv.c:305: structure has no member named `next' w95cv.c:305: structure has no member named `prev' w95cv.c:307: structure has no member named `waitTail' w95cv.c:308: structure has no member named `waitTail' w95cv.c:308: structure has no member named `prev' w95cv.c:311: structure has no member named `next' w95cv.c:311: structure has no member named `prev' w95cv.c:323: structure has no member named `inCVWaitQueue' w95cv.c: At top level: w95cv.c:339: parse error before `&' Cant figure out what got it to compile before. I have checked and MDCPUCFG_H is _win95.cfg OS_TARGET is WIN95 OS_ARCH is WINNT (is this correct for building a win95 target?) I added some code to w95cv.c like so: #ifndef _WIN32 #error xxx #endif and that didnt trigger so _WIN32 is being defined in _WIN95.cfg like it should be. 1.anything wrong with the patch as it stands now? Did I do everything in a portable way? 2.any ideas whats wrong with the build (I did a make distclean and then a autoconf then a configure to make sure it was all clean)? this output is with cc=gcc cxx=g++ having cc set to /bin/gcc (or another cygwin path) also works Setting it to a windows path doesnt work Ideas there are also usefull

win95cv.c expects the struct _MDCVar defined in _win95.h, rather than the one from _winnt.h, probably because of the difference between OS_ARCH and OS_TARGET. You might try asking in the nspr newsgroup for details about the various Windows version builds available. One way to deal with the path thing might be to build from a vanilla DOS shell with cygwin's /bin in PATH so that the tools get found, and possibly a few other environment settings (e.g. SHELL, C_INCLUDE_PATH) to get things running. The batch file that creates the cygwin shell should indicate what's needed.

I managed to get it working. I reran configure with --enable-win32-target=WIN95 and it works. Mabie I didnt run configure properly last time. Anyway, that patch (with the correct stuff for configure) compiles and links no problems. Now I need someone to go over it and check: 1.Did I do everything right? 2.Did I make any mistakes? 3.Does the resulting DLL accually work? 4.Is this code good enough for the mozilla project to use? and 5.If there is anything else about the patch that anyone wants to mention. Now I am going to work on the next bit of the lizzard.

Accually, can that. It doesnt build with GCC yet. It does, however build with MSVC (and those times it was building, I think I forgot to set CC before calling configure) More info: For some reason, something (cygwin GCC perhaps) is defining WINNT. So I added code to w95cv.c that will undefine WINNT if WIN95 is defined. The fact that w95cv.c is being built and WIN95 is defined means that the build process is building the win95 target so if WINNT is defined, its a problem with either the build system (I ran configure with --with-mozilla and --enable-win32-target=WIN95) Now it builds up to the step where its doing the resource files, seems like I need to figure out what cygwin program to use to make the RC files into RES files.

Resources are compiling now, just got to figure out the link problems and it should be good to go for NSPR with cygwin,mingw32 and w32api. I am passing --with-mozilla and --enable-win32-target=WIN95 to configure. (building with --enable-win32-target=WINNT isnt supported and wont be) New patch will be posted after I figure out the link problems.

Here is the state of play with patch v4 building with --enable-win32-target=WIN95 and --with-mozilla gets up to the link stage but then bombs out with errors about cant find API functions, I am working on that one. Have tried some linker stuff that helps a little. Its finding the libraries but not the functions within, dont know why. Also I cant seem to convince it to properly link to the mingw32 libraries. (its not finding the mingw library files if I add -lmsvcrt etc) building with --enable-win32-target=WINNT builds up to ntio.c but then complains that the defintions of some of the functions in that file are different from the primpl.h file. Anyone here want to tell me why and what to do to fix it? other than that, so far so good. Let me explain some of the things I have done in the patch: All changes to the build process are done with NS_USE_GCC as recommended by seawood. The changes to now.c are needed since for some reason cygwin with mingw doesnt like something within the code (not sure what) The changes to _winnt.h are needed to get something to compile properly. ntintrval.c changes are because gcc doesnt like nameless unions. the changes to ntio.c and w95io.c are to do with the nameless unions thing and also a problem with cygwin/mingw32 not having a mbstring.h file. win32_errors.c was changed because the windows socket errors arent pulled by cygwin header files unless you include winsock.h the changes to w95dllmain.c and w95cv.c are because of a problem with cygwin and mingw32. For some odd reason, cygwin with mingw32 #defines WINNT as an intrinsinc (just like it #defines __MINGW32__). Currently, what I have is a kludge. Any suggestions of how to fix this without changing cygwin/mingw (which isnt an option since it appears as though this stuff is hardcoded somewhere) or requiring heaps of effort would be appreciated... Best way IMHO is to add the check to some global header file that gets pulled in before the code that pulls _winnt.h or _win95.h

Can you use ifdef NS_USE_GCC ... else ... endif instead of ifndef NS_USE_GCC ... ? It's more readable that way (at least imho). Also, please don't use tabs (you used them in at least one place).

oh yeah, one more thing: you have rather many lines like this: + ifdef NS_USE_GCC + $(CCC) -o $@ -c $(CCCFLAGS) $< + else $(CCC) -Fo$@ -c $(CCCFLAGS) $< + endif What about doing something like this: ifdef NS_USE_GCC OUTOPT=-o\ else OUTOPT)-Fo endif and later always use $(CCC) $(OUTOPT)$@ -c $(CCCFLAGS) $<

I fixed the NS_USE_GCC stuff and I removed any tabs from any sourcc code files, left them in the makefiles since AFAIK tabs in makefiles are needed. As for the outopt thing, I was just going by what had been done before in similar case (for example, these lines in pr/src/configure.in ifeq ($(MOZ_OS2_TOOLS), VACPP) $(CC) -Fo$@ -c $(CFLAGS) -I$(OBJDIR) $< else $(CC) -o $@ -c $(CFLAGS) -I$(OBJDIR) $< endif

I would obsolete the old patches and mark this one needs-work but I dont have the bugzilla privilages to do so. The folowing open issues relate with this patch: 1.use of tabs in the wrong place. I cant find anywhere in the source files that I am using tabs and I dont know enough about makefiles to know where it is and isnt ok to use tabs there. 2.the thing about OPTOUT. Since its already done (as I mentioned) for OS/2 the way I did it so unless anyone says otherwise, I am just folowing by example. 3.the issue with cygwin #defining WINNT by standard. The fix here seems to be to find a global header file that gets used somewhere and add the test code so that it says #ifdef WIN95 #undef WINNT #endif like I did on the local files. and 4.the problem with the definitions in ntio.c not maching with primpl.h I dont know how they compile on MSVC or why they are that way, to me it seems like I should just change the prototypes to match. Before you ask, yes, I did make sure that I have the latest copy of both primpl.h and ntio.c. the definitions in w95io.c do match with primpl.h

Comment on attachment 79133 [details] [diff] [review] patch v5 Hrm. So with all of this activity, I started looking at the mingw port again and some of these changes will definitely clash despite the fact that cygwin's -mno-cygwin is supposed to just "cross-compile" to mingw's runtime. We're going to have to figure out a way to distinguish between the 2 versions of gcc. I'll attach those changes in a bit. Wrt point 2, I agree with biesi that we should be using $(OUTOPTION) where possible like we do in mozilla/config/rules.mk. Those rules only differ by the output option. I've been using the following construct for denoting a non-gcc/win32 ifdef: ifeq (_WINNT,$(GNU_CC)_$(OS_ARCH)) We'd probably have to rethink it if we get yet another win32 compiler with yet another cmdline syntax but it works for now. Wrt point 3, adding -UWINNT to DEFINES in nsprpub/configure.in seems to work around gcc's unconditional define of WINNT without a problem. I only see a change to pr/src/Makefile.in. Did you get libplc & libplds built as well?

no I didnt get those other libs built yet. I am having linker trouble somewhere, it spits out lots of errors about not being able to find the windows API functions, even thoug I checked with verbose and LD is definatly pulling in the library files needed. What differences are there between mingw and -mno-cygwin? The reason I chose cygwin with -mno-cygwin over mingw itself is largly because mozilla needs parts of cygwin in order to build and I thought that would make it easier. As for the output option thing, what should I do? Start using outoption? How/where should I implement it? Should I fix the OS2 stuff as well? As for detecting GCC (since all the places I am checking are already under a check for "are we building on win32" anyway, I just check for NS_USE_GCC. Thanks for the info about -UWINNT, I will use that and remove the existing kludge code.

> What differences are there between mingw and -mno-cygwin? From http://www.xraylith.wisc.edu/~khan/software/gnu-win32/mno-cygwin-howto.txt , "Using -mno-cygwin is really just a specialized and simplified case of cross-compilation, where you're shielded from some of the usual pains of cross-compilation. " . Since you had to make additional changes to get libnspr to compile, my guess is that either cygwin is using an older version of mingw or somehow the cygwin gcc frontend is tainting your compiles. I'm using mingw 1.0.1 snapshot from http://www.mingw.org/ . Using cygwin's gcc would simplify things but my two-year-old impression is that cygwin's gcc is usually behind mingw's in terms of targetting native win32 code. Maybe that has changed but it doesn't look like it. Hopefully, both compilers will sync up with the pending gcc 3.1 release and make this a moot point. > As for the output option thing, ... See mozilla/config/rules.mk and search for OUTOPTION...or wait for me to attach the mingw patch.

This patch also NSPR to build using the mingw 1.0.1 snapshot. env CC=gcc CXX=g++ ./configure --enable-win32-target=WIN95 The patch incorporates most of the code changes from the previous patches, uses OUTOPTION, and tweaks some rules to build DLLs using dllwrap & dlltool. I also switch from using AC_PATH_PROGS to AC_CHECK_PROGS to avoid dealing with cygwin path issues when using mingw's make. Some of the pr/tests work but most fail. :-/ I suspect that's not normal.

# Bug 122433 workaround: disable global optimization (-Og-) on ntio.c. ifdef BUILD_OPT ifeq ($(OS_TARGET), WINNT) +ifdef NS_USE_GCC +CFLAGS := $(subst -O%,,$(CFLAGS)) Hm... I wonder if that bug also occurs with GCC compilers... maybe it's a MSVC specific problem and works with gcc even with optimization?

Comment on attachment 79133 [details] [diff] [review] patch v5 Marking obsolete since seawoods idea of using mingw makes more sense

Comment on attachment 79142 [details] [diff] [review] mingw gcc patch v1 marking needs-work since the nspr4.dll file that gets built with this patch doesnt work.

more info on whats causing some of the problems. I used GDB to step through affinity.c and it crashed with debugbreak on line 341 of nsprpub/pr/src/threads/combined/prulock.c (i.e. the assert triggered). Next question is: Why is it asserting there and what do we do to fix it? (I suspect that affinity isnt the only test affected by whatever this problem is)

I think I figured out the main symptom of the problem. PR_JoinThread calls PR_Lock. PR_Lock sets the owner of the lock to be the result of _PR_MD_CURRENT_THREAD which I assume returns the current thread. Then PR_JoinThread executes a while loop that calls PR_WaitCondVar Then PR_JoinThread calls PR_Unlock. This also calls _PR_MD_CURRENT_THREAD and checks that the result from that call is = to the owner of the lock. Somehow (no idea how, I dont know enough about threads and especially about NSPR threads) the return value from _PR_MD_CURRENT_THREAD is changing between the call to PR_Lock and PR_Unlock, thus triggering the assert.

Basically, for NSPR you can use either native threads or the pthread library. Three years ago, cygwin thread support was inadequate for NSPR; I would hope things have improved since. Check the cygwin/mingw docs to see if there are any wrinkles to using threads. For instance, you may have to add a flag to tell the compiler/linker it's a multithread program. There's also the pr/tests/threads.c test you might want to try first to make sure threads are being successfully created before tangling with locks.

I figured out what I hope is the problem. GCC doesnt understand the __declspec(thread) keyword from MSVC and thus, variables that should be thread local arent being made thread local. Therefore, its not going to work :)

You might try using pthreads. See http://sources.redhat.com/pthreads-win32/.

Bah. :) It worked once before. It shall live again! Especially since I just stumbled upon the _pr_use_static_tls variable. It looks as though __declspec(thread) doesn't work when the library is dynamically loaded (see comments in w95dllmain.c) so it uses the Tls* functions as a fallback. (Sidenote: it's very confusing when both the Tls* functions and the compiler directive are referred to as "TLS".) When I force this variable to be FALSE , `make -C pr/tests runtests` works (minus a handful of tests)!

So, anyone know what changes I need to make above and beoynd the mingw gcc patch v1 above in order to get everything to work for NSPR? Now I can continue work on the next piece of mozilla, whatever that may be (most likely XPCOM is a good place to start)

Patch updates: Forces _pr_use_static_tls=FALSE for __MINGW32__ Fixes the incorrect inline asm that was causing atomic adds/decrements to fail. Syncs the pr/test/Makefile.in runtests target with the ksh script (that I was never able to get running on win32). All of the tests are built but only the ones that are known to work on all platforms are actually run. With this patch, all of the tests passed for my gcc/-win32-target=win95 build except the sockopt test. For some reason, it was dying with the following errors: PR_SetSocketOption() PR_SockOpt_IpTimeToLive: PR_OPERATION_NOT_SUPPORTED_ERROR(-5965), oserror = 0 PR_SetSocketOption() PR_SockOpt_IpTypeOfService: PR_OPERATION_NOT_SUPPORTED_ERROR(-5965), oserror = 0 With the same build configuration but using MSVC, they all passed. I'm building on w2k. For my gcc/-win32-targets=winnt build, the initclk & multiwait tests also failed.

Cool. Now that, in theory at least, NSPR is working its time to start on the next component. I am going to make the same changes to the build process for main mozilla as was made for NSPR, set variables up properly, configure, run make and see what happens. Also, are we going to look at getting this new patch into the NSPR tree?

This is the beginnings of a patch for the main mozilla tree to get it to compile with GCC. It works fine up untill configure checks for libidl and glib, then bombs out. Thats the first thing we need to fix.

I was working on this a little bit back in early March, and I got a little bit building. I'll attach the work in progress that I had at the time, since it has a few changes in it that I think you might want (e.g., the now.c changes and perhaps some of the configure.in changes, although I should never have started messing with the XP_WIN{,32}_GCC stuff). I never managed to get the nspr dll to link, so that's how far I managed to build with this changes.

This includes everything thats relavent from dbarons patch (not sure if that patch should be obsolete or not tho) It currently builds up to somewhere in js, anyone want to take a look at what the next step is to get it building? I am passing the folowing options to the main configure script: --with-mozilla --enable-win32-target=WIN95 --disable-ldap --disable-crypto --disable-accessibility

+ DLL_SUFIX=dll use spaces instead of a tab +AC_CHECK_PROGS(EMACS, xemacs lemacs emacs, :) I know, this wasn't added by you, but why does Mozilla look for emacs??

This patch gets past all the js problems but now we have new problems... It compiles all the source files in js/src then it creates the res file then it prints out rm -f libjs3250.so then it prints out a syntax error about a ; being unexpected. What I need to know is whats suposed to happen after the res file gets created, where in the build system are the commands that get executed next? How can I find out whats being executed?

everyone else seems to use __declspec see bug 59195 ms seems to too http://msdn.microsoft.com/library/default.asp?url=/library/en-us/vclang/html/_pluslang_Extended_Attribute_Syntax.asp I think we should just bite the bullet and switch globally.

current patch I have been working on. Stuck until I can get a libidl and a glib that work on mozilla

updated this to the latest copies of config/rules.mk and config/autoconf.mk.in

visual C builds will still compile even if the username has whitespace, GCC builds wont. Making 137059 as a dependancy.

this contains the fix for bug 137059 marking dbarons changes obsolete since current patches include all those changes

What is the status of patches? Are all things completed?

No, the patches arent anywhere near finished.

Here's an updated NSPR patch. Btw, I updated my devel environment to use mingw-runtime-2.0, w32api-1.5, binutils 2_12_90-20020518-1, & gcc 3.1-core-20020516-1 so some of the previous MINGW32 workaround weren't needed.

Here's an updated patch that allows the entire tree (sans ldap & nss) to compile. xptcall mostly works, I think. TestXPTCInvoke works, the modified xptcstubs test (stub_test) works, xpcshell works but none of the graphical apps (winembed, viewer or mozilla) work. There's still the question of what level of support this is going to get and if it's even worth adding to the tree if it's going to bitrot. Whatever. I need to get it out of my tree though so here it is. Things to note: * Mingw w32api has no MFC, ATL, RAS or MAPI support * Link order matters * mingw w32api sometime does weird stuff like using a define to refer a common function like LoadImage to an internal routine LoadImageA. This cause problems when we have our own LoadImage classes. * mingw gcc doesn't like declaring function typedefs with __stdcall * xpcom has so many intramodule dependencies that it should be using all of the _IMPL_NS_submodule defines when compiling the entire module * mingw gcc doesn't implement declspec(naked) so xptcall was a pita to get working * "interface" is a c++ keyword to mingw w32api * mingw gcc doesn't like anonymous structs (see nsWindowsHooks.h) * there are namespace issues when attempting to use HKEY_* defines as local variables

Well once mozilla sucessfully builds and runs on GCC, all you need is someone to set up a build box to regularly test it (even if it only built once a day or something that would still work), if it wont build or run for some reason, someone can look into it and fix it.

Well, we saw how well waiting for that mysterious "someone" worked with the motif port and now the qt port. Are you volunteering to be that "someone"? And "once it successfully builds and runs" also implies that "someone" is going to take it that next step. It's not going to evolve on its own.

So Chris, is this work or a hobby? If Netscape is paying to get this going then surely they can afford to throw an old crummy box on tinderbox to run this. Otherwise it was wasted time.

Afaik, Netscape has no interest in this work. Certainly no investment as it was done on my own time using one of my spare machines (slag's back to doing the beos tinderbox). As I wrote to several members of mozilla.org earlier, it was mainly for hack value. I've been interested to see if this could be done since 1999. Now that it's almost done, the question becomes what to do with it? IMO, no maintainer == bitrotten code. It's just a matter of time. I think that the assertion of not being netscape backed == waste of time is invalid. If it's not backed by mozilla.org, then it's a waste of time as it shouldn't go into the tree. But that gets us off into a completely off-topic discussion regarding who controls or should control the tree.

Who controls the tree? mozilla.org, duh. We're happy to have well-owned build fu like this, but that takes us back to the real quesiton: not who "controls" the tree, but who will own these files and keep things from rotting. If we add a ports tinderbox and it turns red, will anyone in the community fix the problems (with help from those whose changes were problematic, if needed)? Who is that "anyone"? /be

Sorry, my comment came out harsher than I meant. I meant that *IF* netscape had paid for this (which turns out to be false) then it would be foolish of them not to go the next step and donate a tbox machine for it to keep it from bitrotting. But since this wasn't a Netscape project we'll have to look for someone else to adopt it.

A tinderbox would be a good thing. Even a $200 486 that takes all day to do a pull & build would probobly suffice, we just need some automated setup to make sure that it builds and that basic things work. As for the issue of who fixes the problem, if the tinderbox is listed on the ports, someone will see it and possibly fix it. But remember that the main reason for doing this is to enable people to build mozilla (and thus help contribute, fix bugs etc) with a 100% free solution on windows. (linux already uses a 100% free build setup AFAIK) Chris, this moz mingw v6 patch, I got some questions: 1.which version of mingw & related tools is required to build it? (and where do I get them) and 2.just exactly what do I do to get CVS to give me the exact code I need to use to patch this?

Ok, let's go down the list: 1) someone needs to make the par'd down code work (ie, make mozilla run) 2) someone needs to complete the port to get it on par with the other win32 port (wrt MFC, ATL, etc) 3) someone needs to provide a tinderbox 4) someone needs to pay attention and actually fix the tinderbox if it breaks While those sound like minor commitments when you have the entire community behind (or at least aware) the effort of maintaining the port, they are fairly major when you have no real developer support. We've already seen what happens (and is happening) when a port is left up to "someone" to fix: motif - dead, qt - dying. Those are ports that only had to reimplement toolkit specific pieces, not OS/runtime specific pieces or implement anything new. And yes, we actually had a motif tinderbox at one point, executor. It was always red and got decommissioned when some of us made a concerted effort to rid the ports page of the "oh, it's always red, ignore it" stigma. Ignoring the differences in the perceived reasons for doing this, if the code isn't maintained and bitrots, it doesn't help anyone contribute. In fact, it detracts from their contributions as potential contributors can wind up wasting time on attempting to get something usable out of code that the rest of the community is indifferent to. 1. > Btw, I updated my devel environment to use > mingw-runtime-2.0, w32api-1.5, binutils 2_12_90-20020518-1, & gcc > 3.1-core-20020516-1 so some of the previous MINGW32 workaround weren't needed. It wouldn't hurt to grab gdb either since msdev can't debug gcc generated objects. See the downloads page at http://www.mingw.org/ . I just remembered that I did make a minor tweak to one w32api header file to get rid of a redundant function declaration. I think it was in mbstring.h but I'm not sure. When I reboot slag, I'll check it out. 2. The current CVS trunk should work. If it doesn't, then you can try pulling from '2002-07-23 09:00 PST'. And yes, you'll need to apply both the moz & nspr patches.

I doubt you will be able to get MFC and ATL working on mingw as they are microsoft only libs.

> Ignoring the differences in the perceived reasons for doing > this, if the code isn't maintained and bitrots, it doesn't > help anyone contribute. I would speculate that there are a significant number of people who currently can't build Mozilla, but would be able to do so if it would build with cygwin. Getting it to that point is hard. Once it reaches that point, it should go in the release notes, and the process of accumulating contributors who are using MS platforms but don't have MSVC can begin. It is well worth noting that the majority of all non-server PCs fall into the category of "Windows, but without MSVC". Sure, most of those people aren't developers, but if even a small percentage of them are, it would be enough.

*** Bug 159723 has been marked as a duplicate of this bug. ***

In response to bug 159723 comment 4: 1) Microsoft no longer sells Visual C++ 6.0. 2) Microsoft no longer sells optimizing Visual C++ separate from the rest of Visual Studio. 3) pricewatch.com > Software > Business (which is often even cheaper than a brick and mortar retail store) doesn't have anything for less than $200 except for academic versions. 4) Which specific comments do you refer to? 5) If I have to, I'll pitch in some $ for tinderbox hardware if it helps m.o bootstrap compilation of Mozilla away from a compiler that costs more per seat than the whole rest of the computer. I'd like to add that the whole thing is a moot point if MSVC's non-optimizer is better than GCC's -O2.

Remember that the idea here is not to completly migrate mozilla away from Visual C++ but instead to offer an alternative to those people that dont own visual C++ and want to contribute to mozilla development beyond bug reports and simple UI hacking with patchmaker or whatever. I think that, once it actually builds and runs with the core functionality intact, we can look at getting it into the tree and getting decent build documents available. Once this is done and a tinderbox is setup, I think that people will start using GCC to hack mozilla and fix bugs etc. The build process should: A.not require anything costing money except a PC with a copy of windows installed and an internet connection and B.should have clearly defined build setup steps (go here and download this, then go there and download that etc) If someone using visual C++ checks code in that breaks GCC builds, someone who builds with GCC can fix it.

1) Just because MS doesn't sell it direct doesn't mean that it's no longer available. I saw a copy at Frys a couple of months ago. 2) I already addressed that problem (MS' "incentive" to buy MSDevStudio) in my previous comment 3) Amazon carries VC++7 standard for $99.99 (with same MS caveat as above). MS sells it direct for $109 so I assume that you were referring to the full studio version? 4) Comment 58 & comment 66 would be the specific comments referring to the lack of parity between the two toolchains but the rest of the bug is worth reading. 5) staff@mozilla.org would be the people to speak with about monetary donations. The whole thing is a moot point if we have people just saying what needs to be done rather than actually doing it. Contributors wanted. Maintainers needed.

I doubt you will ever get MFC or ATL building on GCC/Mingw/Cygwin/whatever. But IMHO it doesnt matter that much since MFC and ATL arent essential to building mozilla. Doing a LXR on the trunk for files that include ATL (I searched on "<atl") reveals that its only used in tools/preloader, embedding/browser/activex and widget/src/windows/accessable.cpp I dont know how important tools/preloader is and how its use of ATL is going to be a problem but I think the other 2 can be disabled with build options. As for MFC (search on "<afx"), its used in /extensions/layout-debug/plugin/npdebug.rc (that file #includes afxres.h) /config/makedep.cpp (uses afxcoll.h and afxtempl.h) /embedding/qa/testembed/ (this folder uses the entire framework) and /embedding/browser/activex/ (again, entire framework used for some of this stuff) I am 99% certain we can get away without building those 2 /embedding folders in GCC/win32 builds, not sure what to do with the /extentions one and the /config one though.

Now that GCC 3.2 is out, does it make sense to use it (once its ported to MinGW of course) for this?

If someone can do the hard part (make this work), I could possibly step forward (assuming no-one else does) to basicly update the tree every so often (as often as time permits) and do a rebuild to see that it still builds with GCC on win32 (and if not either I could fix it if I know how or else it can be fixed by someone else)

About #include "afxres.h" in /extensions/layout-debug/plugin/npdebug.rc: You can get rid of this by replacing it with "native" Win32 includes. You just have to replace the #include "afxres.h" by 2 includes : //#include "afxres.h" #include "winnt.rh" #include "winuser.h" You must also modify the TEXTINCLUDE that is used by MSVC when regenerating the file after resource editing through the GUI: 2 TEXTINCLUDE DISCARDABLE BEGIN "//#include ""afxres.h""\r\n" "#include ""winnt.rh""\r\n" "#include ""winuser.h""\r\n" "\0" END I've not tested this with Mingw, but I'm successfully using this trick with MSVC because I've not installed (and will never install) MFC so I haven't afxres.h.

Hi folks, I am one of the Wine (http://www.winehq.org) developers, and I took on the task of porting Mozilla over to Wine. This port would allow the Windows codebase to be run on Linux. From Wine's perspective, having Mozilla compile, link, and run under Winelib would be a amazing feat, and a super test case. I would like to note that running the native Win32 build of Mozilla under Wine works just fine. I think having such a port would benefit Mozilla as well, and BTW I am willing to maintain it. Needless to say, porting Mozilla to Winelib requires a working MinGW port first. I've discovered this bug by accident, but I'm glad to see that a lot of good work has gone into it already. Unfortunately, it seems the work is in danger of falling by the wasteside, and that would be a pitty. If I undertand correctly the status of this bug, the patch allows Mozilla to build under MinGW, but noone is willing to maintain this. If this is the case, I suggest the following plan: -- Support gcc 3.2 and up only. This will alllow us to drop a lot of the ugly ifdefs from the patch. -- Break down the patch into a controversial part, and a non controversial one. This way, the non controversial part can go in the tree right away without the fear of bitrotteness. -- Once we've brought the MinGW specific part down to a minimum, someone might step up to maintain it. In theory, that part should be so small that would be no problem for anyone to maintain it. What do you guys think? What is the process of pushing some of the changes, such as these: - WORD wsz[MAX_PATH]; + WCHAR wsz[MAX_PATH]; into the official tree? I hope everyone agrees that such changes can go in without the fear of ever bitrotting, as they are used by the other Win32 port as well. Besides they make sense independent of the the MinGW port.

Dimitrie - Have you considered taking the lead on the MinGW port itself? It seems to me, having read all the above comments, that this would be the most valuable place to start as a contribution to Mozilla. Wish I could do it myself... The original reporter here is also the Assigned To person and he's indicated, in Comment #75 that he's willing to maintain this only if someone else makes it work first.

Dimitrie, the patches here allow it to build but it doesn't run which is a signficant difference. I upgraded to gcc 3.2 a few weeks ago but I'm still hitting the same basic problems with the build. xptcall only works in debug builds. Do you know how to properly implement the equivalent of __declspec(naked) function in gcc? The non-controversial (read: non-mingw specific) parts of the patch are fairly small. To get those in, you'd have to create a separate patch and get the respective module owners to review them. The mingw specific portions are relatively large and shouldn't go in until they actually work.

Mark: I will maintain the Wine port, and since the Wine port uses the mingw port, I will maintain that indirectly. But I'm afraid I can't maintain the mingw port directly as I don't have a Windows box. Dauphin: I'm afraid I don't know how to simulate __declspec(naked) functions in GCC. Can you please explain in more detail why they are needed, I'm sure we can work something out. Now, I want to stress that I think we can reduce the GCC specific part by quite a bit. I can perfectly understand your concern of this port being unmaintained, but this bitroting is caused by the overuse of #ifdefs. With proper care, we can make this patch smaller, and without ugly preprocessor stuff. For example: -- gcc 3.2 supports anonymous structures and unions in C & C++. This will get rid of the terrible #ifdefs that are poluting this patch. And this is a sizable chunk. -- did anyone check naked support in gcc 3.2? Did you try using __attribute__((naked))? It should work, AFAIKT. Something like this should work fine: #ifndef __GNUC__ #define NAKED __attribute__((naked)) #else #define NAKED __declspec(naked) #endif somewhere in a base include, and then simply use NAKED where you need a naked function. -- we should not need things of this form: +ifdef GNU_CC +OS_LIBS += -lcomctl32 -lcomdlg32 -luuid -lshell32 -lole32 -loleaut32 -lversion -lwinspool -lgdi32 +else OS_LIBS += comctl32.lib comdlg32.lib uuid.lib shell32.lib ole32.lib oleaut32.lib version.lib winspool.lib endif +endif What we want to do here is something like so: IMPORTS = comctl32 comdlg32 uuid shell32 ole32 oleauth32 version winspool gdi32 OL_LIBS += $(IMPORTS:%=$(PRELIB)%$(POSTLIB)) where PRELIB, and POSTLIB are determined at configure time, or if that is not good enough, we can have: ifdef GNU_CC PRELIB=-1 else POSTLIB=.lib endif As you can see, this code can not get bitrotten, because the part that needs to be maintained (the list of libs) is used _all_ the time. I can go on, but do you guys agree that this is the way to go?

xptcall uses __declspec(naked) for the win32 implementation. There are a couple of functions that are implemented in inline asm. The patch works around that requirement for gcc but something's still not right for the optimized builds. http://lxr.mozilla.org/seamonkey/source/xpcom/reflect/xptcall/src/md/win32/xptcinvoke.cpp#80 No, I haven't tried using __attribute__ yet. I'll give that a shot. I have a macro that was implemented for another bug which will simply that library issue.

Dauphin: I am curious to see your new patch. BTW, are the current patches still valid? Are they against HEAD or the 1.2.x branch? Anyone care to update these patches to HEAD? <g>

A slightly (but not much) cleaned up patch for NSPR. Upgrading to gcc3.2 did remove the need for a few of the anonymous struct/union ifdefs. I also cleaned up the runtests target in pr/tests so that it runs the runtests.ksh script. For the win95 configuration, only the sockopt test failed. For the winnt configuration, cltsrv, multiwait, nonblock & sockopt failed.

Cool stuff! I was just doing the same thing right now: cleaning up the gcc v3 path for gcc3.2. The new version looks much better IMO, thanks! Listen, why do we bother testing for DLLWRAP, we don't seem to make use of it. Also, even if we need it, we should just use gcc -shared instead, it seems to be the recommended thing to do these days. From your POV, what does it take to get this one integrated in the tree? I know there are a few tests failing, but it seems relatively clean, and in good enough shape to go in, no?

We use DLLWRAP to create the shared library (see the MKSHLIB definition). I haven't gotten around to verifying that 'gcc -shared' works properly yet. Once we have confirmation and we agree to drop support for pre-gcc3.2, then we can go ahead and switch. Remember that these patches are carried over from the mingw gcc 2.95.2 days and have not been actively worked on. In general, we need a review by the module owner & a superreview as well as the commitment that this is what we want to do (ie, support mingw builds). For NSPR, that means that wtc needs to review the new changes.

This patch contains only the build changes which shouldn't affect any builds. It adds the EXPAND_LIBNAME & EXPAND_MOZLIBNAME macros to handle the conversions of the base library name into a form usable for linking. The rest is mainly reordering the libs so that dependencies are resolved in order.

Comment on attachment 110570 [details] [diff] [review] nobrainer build changes v1.0 r=dmose

Yes, I noticed the MKSHLIB def after I've send the comment. A few things: 1. Is there any doubt that we want to be able to compile with gcc? From many points of view it's very important to be able to have a _free_ project build with free tools. I'm not going to rehash all arguments here, but your comment scared me a little :) 2. I strogly suggest not supporting gcc 2.x. It adds to much ugliness to the source, and I don't think the benefit is worth the pain. Moreover, it will make the patch less acceptable, so we all use. Besides, is not like we have very few requirements for building mozilla anyway <g> 3. You're latest patch did not apply cleanly to HEAD. It had a small conflict in configure.in. What did you make it against? Moreover, it failed to compile and link in multiple ways. Most notably, it failed to compile config/now.c because of the __int64 business, and it failed to link a bunch of things. How did you get to run the tests? 4. We're currently linking against cygwin, which is not good. We need to pass -mno-cygwin to the compiler, and linker/dllwrap so that we link against msvcrt.dll instead. This will make this build a lot more useful. Unfortunately, I'm new to the build system, and I can't quite find where to pass the flags along. Second, I hacked the Makefiles to do it, but the test programs don't start complaining they can't get initialized. Bummer. I'd be glad if I can get this thing to run even if it's linked with cygwin, but we really need to get rid of this dependency. 5. Where does dist/include/nspr/md/_winnt.h get created? It is defining 4 variables (at lines 461, 479, 495, 511) with the __declspec(thread) which does not seem to be supported by gcc. First off, this produces a lot of anoying warnings we should silence. Second, how do we get around for semantics with these buggers. Didn't you run into this? 6. Once we're happy with the patch for NSPR, can you take care of pushing it to the appropriate people for inclusion? That's it for now :)

This is probably going to involve rehashing previous comments so reading the entire bug is recommended. 1) There is doubt if a) there's no one to maintain it and, more importantly, b) it doesn't work. There's no point in having a half-implemented port in the tree waiting to bitrot (see previous comments about motif & qt). 2) Fine by me. I don't often work with mingw so 2.95.2 is still the "stable" version in my book. 3) The Mozilla trunk does not build against the HEAD branch of NSPR. You need to pull the tree using the build instructions at http://www.mozilla.org/build/win32.html . 4) If you're linking against cygwin, that's because you're using cygwin gcc. This patch doesn't support cygwin gcc (see comment 31). 5) _winnt.h is checked into the tree. Yes, I saw the declspec warnings. The normal gcc builds have thousands of warnings so I'm sorta immune to them by now. > how do we get around for semantics with these buggers I'm not following. Could you elaborate? 6) Outside of the no-brainer changes, I'm skeptical of pushing for anything until we at least get a window up. So far, just a handful of the debug xpcom/js tests work. wtc's also on the CC list so he'll review the changes when we state that we're ready to land.

Thanks for the comments. I've read the bug, but it's long and I might have missed stuff, my appologies. But back to your response: 1) As I said, if done properly we can reduce the posibility of bitrot to negligable levels. motif and qt are a different story. Your nobrainer patch is a good step in that direction, and here are some good things that can be pushed, I believe. But nontheless, we already have someone willing to maintain it if we get it working, and there may be others (including me). 2) So let's take an executive decision now and say wew only do gcc 3.2. We already have a lot of things to deal with, we don't need the additional agravation. Once that is in the tree, and working, we can start considering gcc 2.x if there's still a strong need. 3) <blush>I will read them again.</blush> 4) Yes, I am using cygwin's gcc, but that should not be a problem. Both cygwin and mingw gcc support -mno-cygwin, and they do the right thing so we should always specify it, no? 5) I think we should silence them. We get 4 warnings for basically every compiled file, and they can obscure important stuff. Plus they _are_ anoying. :) As for the semantics bit, I guess the __declspec(thread) specify that the variable should be thread local, no? If that's so, the code expects that only one thread can access them, but if gcc does not support this attribute, this assumption will be violated... How do we get around this problem? 6) That's fine by me. The nobrainer one looks very good, it should go in IMO. With that in, and with gcc 3.2, the mozilla patch should shrink considerably. Moreover, there are other bits in there that can go in. But beyond that, I was refering to NSPR: if we get the dang thing to build (without a ton of warnings), and the tests to run, it seems to be the patch should be ready to go in. But we can debate this when we get there, I think :)

I'm too tired to break this up any further so here's the rest of the changes.

as for declspec(thread): I think this can be used for gcc/g++: http://gcc.gnu.org/onlinedocs/gcc/Thread-Local.html but, I have no idea since when gcc supports that. >The nobrainer one looks very good, it should go in IMO. it is in already :)

hm, http://article.gmane.org/gmane.linux.debian.devel.gcc/1575 indicates that __thread is not part of 3.2...

I would suggest that gcc 3.x be used. This is because it is available, and it makes the patches easier. Is it less stable than 2.95, well it doesn't really matter IMHO as we are talking about Win32 which isn't overly stable itself. I thank everyone who is working on this. I also beleive that a free browser should/must be able to be built with free tools on supported OS's.

my experience with working with both gcc 3.2 and 2.9x on reasonably complex projects (though not as complex as Mozilla) hasn't led me to believe that 3.2 is any worse. it may in fact be better. It is after all a stable release...

Folks, RedHat ships gcc 3.2, cygwin does, etc: it is _stable_. This is not the issue. The issue is if we can ask people to upgrade. Given that right now people are asked to _buy_ a *Microsoft* product to help develop on a vlunteering basis a free product that is the only competition to MS IE, ... well, I think asking to upgrade to gcc 3.2 is so small in comparsion that it's not worth discussing. Really.

For the purpose of building Mozilla, you only need to port the "WIN95" configuration of NSPR. It is not necessary to port the "WINNT" configuration. I'd like to see how NSPR's sockopt test fails. You should ignore the multiwait test, which is somewhat broken. The failures of the cltsrv and nonblock tests are serious, but since they only fail in the WINNT configuration, they have a low priority. If gcc has no equivalent of __declspec(thread), it is possible to modify NSPR so that it doesn't use __declspec(thread). This has a low priority because only the WINNT configuration is using __declspec(thread).

I agree with wtc, but maybe for different reasons. If gcc can be made to work with Win 9x/Win Me, then that is good (and appears from wtc's comments to be easier). Once that is done, then WinNT (and WinXP, Win2K?) can follow.

* uses gcc -shared -Wl,--out-implib instead of dlltool & dllwrap to create shared libs * added -mo-cygwin flag (though I still have no intention of supporting cygwin gcc) * removed unneeded make variables

Dauphin, the latest patch (NSPR mingw gcc v1.1) looks great. In fact, most of it looks like good old cleanup. Anyway, I have a question: I've got the tree as explained in the docs you pointed me to (make -f client.mk checkout), but I do have this method. I understand CVS well, and I like to know what's going on. Can you please tell me what branch you work off of? As for -mno-cygwin, thanks for adding it. The gcc's in cygwin and mingw should be almost (if not right on) identical, so that's good. Unfortunately, I still didn't manage to get stuff working on my end. Any help on the CVS question will help me greatly, so that we work off of the same thing. BTW, what do you think about wtc's comments Re: WIN95? That seems to solve a bunch of problems nicely, no?

The sockopt test is failing because several of the socket operations appear to be unsupported. I tried linking against libws2_32.a as well but it didn't seem to make a difference.

Dimitrie, some of the modules used to build Mozilla are used by other products so we cannot dictate checkin rules for the HEAD branch of those modules. NSPR is one of those modules (LDAP is another). mozilla/client.mk contains the list of modules that are pulled as well as which specific branches are being pulled. I'm using the Mozilla trunk which is currently using the NSPRPUB_PRE_4_2_CLIENT_BRANCH branch of mozilla/nsprpub. Re: WIN95, we haven't solved anything. If you build NSPR by itself, it will default to using the WINNT configuration. The Mozilla configure script forces NSPR to use the WIN95 configuration. That's the way it's always been. Eventually, those issues will need to be resolved before we can say we have mingw support for NSPR again.

Dauphin: thanks for the CVS tips. Unfortunately, I'm still running into some problems: #cvs up -r NSPRPUB_PRE_4_2_CLIENT_BRANCH #(cd ..; patch -p0 < mingw-nspr-gcc3-v1.0.patch) #autoconf #$ autoconf --version Autoconf version 2.13 #./configure #makecd config; make -j1 export make[1]: Entering directory `/e/dimi/mozilla/nsprpub/config' sh ../build/cygwin-wrapper gcc -o now.o -c -mno-cygwin -g -UNDEBUG - DDEBUG_Administrator -DDEBUG=1 -DXP_PC=1 -DWIN32=1 -DWINNT=1 -D_X86_=1 - DHAVE_LCHOWN=1 -DHAVE_STRERROR=1 -DFORCE_PR_LOG now.c sh ../build/cygwin-wrapper gcc now.o -o now.exe now.o(.text+0x6f): In function `main': /e/dimi/mozilla/nsprpub/config/now.c:94: undefined reference to `__imp___iob' collect2: ld returned 1 exit status make[1]: *** [now.exe] Error 1 make[1]: Leaving directory `/e/dimi/mozilla/nsprpub/config' make: *** [export] Error 2 This is because we don't pass -mno-cygwin to the link stage.

Re: WIN95 -- can't we force the NSPR build to WIN95 when building on mingw, for a start? It would be great if we could do the NT version as well, but it seems the 95 one is good enough, no?

Does checkin in the early morning yesterday break calendar building ? Cf bug 187663 I filled this morning.

Dauphin, thanks for the NSPR test log file. The failure of the sockopt test is caused by several macros not being defined: IP_TTL, IP_TOS, IP_MULTICAST_TTL, and IP_MULTICAST_LOOP. You should find out how to cause these macros to be defined by <winsock.h>. See the comments at the beginning of nsprpub/pr/src/io/prmapopt.c, before #ifdef WINNT #include <winsock.h> #endif and later in the same file where those macros are defined as _PR_NO_SUCH_SOCKOPT if they are not yet defined. Strictly speaking, this is not the right way to implement those socket options on Windows, but I think the mingw port should attempt to use the same hack at the moment. Is it possible that mingw automatically define _WIN32_WINNT? If so, what's its value?

Wan-Teh, thanks for the pointer. _WIN32_WINNT is defined as WINVER which defaults to 0x0400 under mingw. Those macros were defined in ws2tcpip.h. It turns out that I needed to link against -lws2_32 instead of -lwsock32 in order to get a version of getsockopt that understood those macros. All of the tests pass for the win95 config now. While doing some cleanup on the main tree, I ran into a problem stemming from using PRUnichar & MOZ_UNICODE. It was pointed out to me that we're using a conflicting define in prtypes.h for PRUnichar if MOZ_UNICODE is defined. MOZ_UNICODE is defined by default when building the Mozilla widget module. I modified prtypes.h to use a set of ifdefs that's closer to the original ones in nscore.h but we should really just think about moving that define into NSPR wholesale which would include the configure test for a 2-byte wchar_t.

* Fixed the PRUnichar problem so that PRUnichar is a wchar_t like msvc builds * Use -shared -Wl,--export-all-symbols -Wl,--out-implib -Wl,$(IMPORT_LIBRARY) to create shared libs * debug xpcshell works. debug winEmbed, viewer & moz fail. At one point it looked like there was a problem with chrome registration as autoregistration would fail when it was processing the necko chrome file but gdb dies when I try to debug that scenario. * optimized TestXPTCInvoke fails. The arguments being passed from TestXPTCInvoke.exe to XPTC_InvokeByIndex() are being morphed somehow. XPTC_InvokeByIndex(test, 3, 3, var) becomes XPTC_InvokeByIndex (that=0x77fcf348, methodIndex=2013479168, paramCount=4410793, params=0x0) I building using the Mingw-2.0.0 release + the updated (not RC) packages (currently binutils, w32api & mingw-runtime) available from http:/www.mingw.org/ . This is the MOZCONFIG file that I'm using to build with: MIDL='c:/Program Files/Microsoft Visual Studio/VC98/bin/midl' CC=gcc CXX=g++ LD=ld AS=as MOZ_INTERNAL_LIBART_LGPL=1 mk_add_options MOZ_INTERNAL_LIBART_LGPL=1 mk_add_options MOZ_OBJDIR=@TOPSRCDIR_MOZ@/../obj-mingw mk_add_options NS_OBJDIR=@TOPSRCDIR_NS@/../obj-ns-mingw # mingw ac_add_options --disable-md ac_add_options --disable-optimize ac_add_options --enable-debug ac_add_options --enable-debugger-info-modules=^content,^layout ac_add_options --disable-ldap ac_add_options --disable-accessibility ac_add_options --disable-activex ac_add_options --enable-svg #ac_add_options --enable-crypto ac_add_options --enable-extensions=all,-transformiix ac_add_options --enable-calendar

Looking at one of the patches, I see a reference to MIDL Does mozilla actually require MIDL (only available with visual C++ afaik) in order to build on win32? If so, we have to do something about that.

Updated to current CVS tip. Note that for these patches to work, ${MOZ_TOOLS}/bin must come after the cygwin tools in your $PATH. The reason for this is that the "uname" in ${MOZ_TOOLS}/bin doesn't recognize cygwin. Do we need to update moztools?

Oddly, my moztools came with every occurence of \n in glib.h and glibconfig.h replaced by \n\n\n. Once I fixed this with xemacs, my compile became happier. I suspect some weird cygwin interaction.

More code landed on the NSPR branch that used i64 syntax on XP_WIN. Added __GNUC__ bracketed changes to cope with this.

* Merged xptcinvoke.cpp changes to CVS tip. * Only check the version of MIDL in configure.in if MIDL has actually been set. * Get rid of extraneous MSVC switches in HOST_CFLAGS ("-TC -nologo"). * Call BreakAfterLoad on all architectures, not just XP_UNIX * Make BreakAfterLoad always use |asm("int $3")| on __i386, not just on __i386 linux. I haven't marked the old patch as obsolete yet, as I suspect my -TC -nologo changes will break MSVC. cls, i'm not understanding how the existing patch could have worked for you with gcc, however. -TC makes my gcc look for a linker script named "C". Any thoughts? Other misc stuff: - building the trunk gdb with cygwin gcc (not mingw gcc) generates a debugger that's more useful than any of the prepackaged binaries (i.e. it doesn't crash immediately when debugging mozilla). The issue that mozilla seems to be having with the chrome registry is that a bunch of the static const RDF resources returned by the service seem to point off into never never land. I'll debug more on that soon. - the mozilla source tree cannot live in your cygwin home (or any other part of the cygwin tree), or the mozilla builds breaks while attempting to nsinstall stuff (thanks to cls for the tip).

Comment on attachment 111604 [details] [diff] [review] NSPR mingw gcc3 patch v1.4 1. nsprpub/configure.in Why do the mingw tools also need $(CYGWIN_WRAPPER)? AC_SUBST(WINRES) should be removed. AC_PATH_PROGS(RC, ...) seems to be undone by RC=rc.exe later. 2. In some places you are using __MINGW32__ instead of __GNUC__. Is the distinction intentional?

dmose, I havent looked at the patch but something is broken if you are using HOST_CFLAGS. HOST_CFLAGS is only used when cross-compiling or building nsinstall. nsinstall comes with wintools.zip so it is not built by default for win32 regardless of compiler. The msvc switches are needed to a) force msvc to treat the file as C instead of attempting to autodetect it & b) avoid the annoying msvc copyright on every execution. The autodetection is avoided so that the autoconf c++ tests actually work. The autoconf tests use .C as the name of the c++ file which on a case-insensitive file system causes the c++ files to be treated as C files. wtc, 1) The mingw tools are native win32 executables. They have no knowledge of cygwin semantics so they must be wrapped as well. Yes, the msvc build hardcodes the rc.exe as it always has. 2) Yes, the distinction is intentional. __GNUC__ ifdefs refer to compiler specific changes such as MSVC using i64 to denote a 64bit int and gcc using LL. __MINGW32__ ifdefs refer to changes that are specific to the mingw implementation of the win32 api.

My bad. mkdepend also uses the HOST_CFLAGS rules due to bug 179895. I missed this problem because I had makedepend installed from Cygwin's XFree86 package.

Turned out the problem with the weird HOST_CFLAGS goop was due to the need to bootstrap mkdepend. This patch only adds "-TC -nologo" when MSVC is being used.

* fully qualified call to nsMsgProtocol::PostMessage to avoid collision with a windows macro * added settings in nsXPCOMPrivate.h to tell the GRE to look for libxpcom.dll in this build, not xpcom.dll * fixed .i rules (build an intermediate preprocessed file for debugging) to work on cygwin We still crash in the chrome registry with bogus RDF resource constants. Now RDF resources are stored in a PLDHash, so I'm betting that the problem is some sort of object layout issue, as PLDHash is historically sensitive to these.

Comment on attachment 111925 [details] [diff] [review] moz mingw gcc3 patch, v1.4 Whoops, attached the wrong file.

I did some editing. Note the changes I made to nsprpub/configure.in regarding WINDRES and RC. I omitted the changes in nsprpub/pr/src/md/windows regarding _pr_use_static_tls and the runtests makefile target in nsprpub/pr/tests/Makefile.in because I think they still need work, but they are not critical to making mozilla build on Win32 using mingw gcc3, so they shouldn't block the checkin of the rest of the changes.

Attach the correct file for the 1.4 changes. Also, instead of trying to do the inline assembly stuff for XPCOM_DEBUG_BREAK and XPCOM_BREAK_ON_LOAD on all x86 platforms, just do it on x86 platforms running gcc, since other compilers are likely to use a different syntax.

+ifndef GNU_CC ifndef NO_MFC couldn't you, instead, define NO_MFC in win32/gcc builds?

Woohoo! It works! Browsing and mail work (I'm posting this patch using it). Plugins (or at least OJI) don't yet. I haven't looked at the optimized xptcall stuff yet, so it probably doesn't either. Changes: * rules.mk can now build intermediate assembly files (.s) * rewrote RDFContentSinkImpl::InitContainer so that it's not table-driven. Works around a gcc stdcall bug, and is probably faster to boot (calling through pointers to possibly virtual methods turns out be expensive, at least on gcc, probably elsewhere). It's also easier to read. Might be a bit larger, however. * made DllMain in widget/src/windows/nsToolkit.cpp |extern "C"| when building with gcc so that the name doesn't get mangled. Before this change, it wasn't getting called at all. * temporarily disabled plugins for __MINGW32__

Comment on attachment 111962 [details] [diff] [review] NSPR mingw gcc3 patch v1.5 I've checked in this NSPR patch.

Do I need to do something to my .mozconfig? I just pulled the cvs and tried to build Phoenix. Or does this not work for Phoenix yet? export MOZ_PHOENIX=1 mk_add_options MOZ_PHOENIX=1 ac_add_options --enable-crypto ac_add_options --disable-tests ac_add_options --enable-optimize=-O2 ac_add_options --disable-debug ac_add_options --disable-mailnews ac_add_options --disable-composer loading cache ./config.cache checking host system type... i686-pc-cygwin checking target system type... i686-pc-cygwin checking build system type... i686-pc-cygwin checking for cl... no checking for cl... no checking for link... no checking for midl... no checking for ml... no configure: error: $(CC) test failed. You must have MS VC++ in your path to buil d. *** Fix above errors and then restart with "make -f client.mk build" make: *** [/home/alanjstr/tmp/mozilla/Makefile] Error 1

Afaik, no one has tried building with phoenix yet. Getting a mozilla window up was hard enough. Besides, it doesn't look like you applied the patch to your tree or you didn't run autoconf after applying the patch so the build wouldn't work anyway.

Here's the first shot at getting NSS working. It builds but crashes with an 'Integer overflow' error in libsoftokn3.dll when using SSL. There were some weird link issues. Apparently, nssckbi.dll & swft32.dll implement some NSPR stub routines so that they wouldn't have to link directly against the NSPR library. That didn't work for me. Even with those stub routines, the linker was still complaining about the _imp__ symbols that were pulled in from the static plc4 & plds4 libs. Plus I think link order still matters so the stub implementation would have to be linked after the $(EXTRA_LIBS) which means that we might need a custom rule. It may be possible to avoid the NSPR direct linkage by using the trick from the fortcrypt makefile and generating a import library from the stub object file and linking against that. For now, I just commented out the stub routines and linked directly against NSPR.

cls: As a first cut it is fine to just comment out the NSPR stub routines and link directly against NSPR. NSS has a test suite in mozilla/security/nss/tests. You need to set two environment variables HOST (the host name) and DOMSUF (domain name suffix, for example mcom.com). If your PC does not have a host name, you can set HOST to "localhost" and DOMSUF to "mcom.com". Then, cd into mozilla/security/nss/tests and run "all.sh". The test output log and results will be in the directory mozilla/tests_results/security/<host>.<n>, where <host> is the value of HOST and <n> is 1, 2, 3, ... The test output is in the file "output.log" and the results are in the file "results.html". Usually you just check the results.html page and make sure that all the test results are "Passed" (in green).

how much of cygwin/mingw32 etc do you actually need ? I'm building daily under Linux (both Moz and Px) I would like to try this Win98SE

Comment on attachment 111962 [details] [diff] [review] NSPR mingw gcc3 patch v1.5 Marking obsolete since this has been checked in.

Latest news: If you've used recent mozilla installer builds, when you run a mingw build in your tree, you'll now need to run mingw mozilla like this: env USE_LOCAL_GRE=1 ./mozilla.exe Otherwise, it'll try and use the installed GRE, which won't work. At some point, we'll want to make the builds compatible. It turns out that not all plugins are busted in current mingw builds. The only real showstopper is that the OJI plugin crashes when it's loaded. The problem appears to be related to the fact that the OJI plugin is an XPCOM-style plugin, and the badness seems to be happening in nsPluginHostImpl::GetPluginFactory(). > how much of cygwin/mingw32 etc do you actually need ? The same cygwin stuff as listed for the windows build, plus mingw (but msys is not necessarily). The mingw stuff can be found at <http://www.mingw.org/download.shtml>, you'll want all the relevant updates & release candidates (ie everything but ada and java).

I've setup /etc/profile under cygwin to define: export CC=gcc export CXX=g++ so I have a slightly different output cf Alan comment #126 loading cache ./config.cache checking host system type... i686-pc-cygwin checking target system type... i686-pc-cygwin checking build system type... i686-pc-cygwin checking for cl... gcc checking for cl... g++ checking for link... no checking for midl... no checking for ml... no then it borks with configure: error: This version of the MSVC compiler, , is unsupported. sounds good that : ) what do you need to define for gcc building so that link etc has an executable ?

bugspam: forgot the autoconf, as Alan appeared to have done when he commented

not quite bugspam: what .mozconfig options / ./configure options are successful builders building with ?

building in cygwin (since dos prompt is forgetting/mishandling path(s)) win98se current break of build : In file included from xpidl.h:50, from xpidl.c:42: c:/MinGW/include/string.h:52: parse error before "void" xpidl.c: In function `main': xpidl.c:144: warning: ISO C forbids nested functions xpidl.c:144: syntax error before '*' token c:/MinGW/include/string.h: At top level: c:/buildtools/windows/include/glib.h:3877: storage size of `value' isn't known c:/buildtools/windows/include/glib.h:3889: storage size of `next_value' isn't known make[5]: *** [xpidl.o] Error 1 make[5]: Leaving directory `/cygdrive/e/mozilla/xpcom/typelib/xpidl' make[4]: *** [export] Error 2 make[4]: Leaving directory `/cygdrive/e/mozilla/xpcom/typelib' make[3]: *** [export] Error 2 make[3]: Leaving directory `/cygdrive/e/mozilla/xpcom' make[2]: *** [tier_2] Error 2 make[2]: Leaving directory `/cygdrive/e/mozilla' make[1]: *** [default] Error 2 make[1]: Leaving directory `/cygdrive/e/mozilla' make: *** [build] Error 2 cdn@emperor /cygdrive/e/mozilla $ which glib.h should it be using ?

We pass most of the tests. The main one we fail is the CA cert creation which causes a number of the subsequent tests to fail as well. It looks like it's failing in PK11_NeedUserInit() at http://lxr.mozilla.org/seamonkey/source/security/nss/lib/pk11wrap/pk11slot.c#2288 because the passed in slot->flags is 32772 which appears to also be passed to the CK_TOKEN_INFO info struct. This causes the return test to fail as 32772 & 8 != 0 . Could this be one of those MSVC initializes vars to 0 by default problems?

Changes to get NSS tests running.

I tracked the cert db creation crash back to the asm file used for the mpi routines in freebl. Whenever a function from that file is called, the program crashes. I suspect that there's a problem with the calling conventions used by pure asm & what's expected by mingw gcc. For now, I decided to use the fallback C implementations of those functions which are slower but work. All of the NSS tests pass now. For some reason, though, I had to manually kill each invocation of the selfserv.exe test app using the Task Manager as it wouldn't die using cygwin's kill command. The browser dies in xpcom when bringing up https://www.verisign.com though. It also dies when pressing the button for form submission so it's probably unrelated to NSS.

It turns out that the https crashing problem is due to the location of nssckbi.dll being hardcoded into my profile (bug 176501). The mingw gcc build is obviously having problems loading the msvc built binary from a separate build tree. If I create a new profile, then https pages load fine and s/imap works.

* Updated to current CVS tip * Account for renaming of zlib to mozz * Enable all plugins except a particular XPCOM style (otherwise machines which have the OJI plugin installed would try to use it and crash). I'm not sure why they crash, though; I thought XPCOM / stdcall would be enough to compensate for existing ABI differences). * fix plugin sdk sample Makefiles to link against gdi32 * change plugin sdk samples to include "windows.h" instead of "afxres.h"

Changes: * Cleanup of configure.in changes. Use the default compiler detection macros but default to msvc for win32. * Removal of various debugging printfs & ifdefs (primarily from xpcom) * Fix mail sending problem cause by calling wrong ::PostMessage

Just removing the diff cruft added by $Id$

* Syncing against the past week worth of changes * Stopped hardcoding HOST_CC & HOST_CXX to cl as it's unnecessary for a normal build. * Automatically turn off compiler-dependency generation when building with gcc on win32. gcc generates dependency info using dos paths which confuses cygwin make. mingw make appears to handle it fine though. I forgot to mention this with the last patch; you have to set CC,CXX,CPP,AS & LD when building for mingw as we default to the MSVC tools. The minimal mozconfig file now looks like: ---> CC=gcc CXX=g++ AS=as LD=ld CPP=cpp ac_add_options --disable-accessibility ac_add_options --disable-activex <--- Currently using the gcc 3.2.2 release candidate, binutils 2.13.90 20030104 RC, w32api 2.2 & mingw-runtime 2.4 packages. Oh, and we have a temporary tinderbox set up on the Ports page.

Let's get this party started...

Do the patches attatched to this bug and/or going into the tree enable you to build mozilla without having Visual C++ or any microsoft SDKs or tools available? If not, what bits of Visual C++ & the SDKs do you still need and what part of mozilla requires them?

The mingw tinderbox is running from a fresh w2k install with only cygwin, mingw & ns7 installed.

Comment on attachment 116377 [details] [diff] [review] msg protocol changes (checked in) if that works, sr=sspitzer

I'm not sure about these changes. They work with gcc & MSVC but I'm fairly certain these .rc files were generated at some point and I'd hate to lose the changes because of that.

Comment on attachment 116379 [details] [diff] [review] cleanup of XP code >Index: content/svg/content/src/nsSVGValue.h >@@ -44,7 +44,7 @@ > #include "nsISVGValueObserver.h" > > // XXX this should be somewhere else >-#if defined(XP_PC) && !defined(XP_OS2) >+#ifdef _MSC_VER > #define STDCALL __stdcall > #else > #define STDCALL This should really be using something from nscore.h, but it doesn't look like there's anything that works for pointer-to-member (like NS_CALLBACK_). Could we make something? Shouldn't you be using __stdcall, or doesn't gcc support it? The nscore.h stuff uses the NS_WIN32 macro to test for Windows. >Index: db/mork/src/morkSearchRowCursor.h >@@ -116,8 +116,10 @@ > virtual mork_bool CanHaveDupRowMembers(morkEnv* ev); > virtual mork_count GetMemberCount(morkEnv* ev); > >+#ifdef NEEDED > virtual orkinTableRowCursor* AcquireUniqueRowCursorHandle(morkEnv* ev); >- >+#endif >+ > // virtual mdb_pos NextRowOid(morkEnv* ev, mdbOid* outOid); > virtual morkRow* NextRow(morkEnv* ev, mdbOid* outOid, mdb_pos* outPos); > Could you change this and the corresponding |#ifdef NEEDED| to |#if 0|? (See our C++ portability guidelines for why. :-) Other than that, sr=dbaron.

Comment on attachment 114294 [details] [diff] [review] LDAP mingw patch v1.0 (checked in) sr=dmose for the client ldap branch

Would it be feasible to adapt the Mozilla makefiles as a project to run under the open-source Dev-C++ IDE? Thanks to everyone who contributed to the progress made on this enhancement!

Marc Rubin contacted me regarding this bug because I had done some work trying to convert MSVC++ project files to Dev-C++ project files. While I was able to get two sub-projects to build using Dev-C++ (which relies on either mingw or cygwin for actual compiling), I couldn't really get the rest of the files to convert and modify to compile properly. The current betas of Dev-C++ 5 allow you to import .dsp files, however, this doesn't always work and usually requires tweaking. Some huge projects such as Mozilla and Amaya are outside the scope of what Dev-C++ is designed for; however, if desired, somebody could work on Dev-C++ since it is Open Source as well to make its GUI more capable with multi-project projects such as Mozilla and Amaya.

Comment on attachment 116379 [details] [diff] [review] cleanup of XP code So after much googling, it turns out that you can apply __stdcall to a function prototype but it has to be declared *after* the function prototype, eg |typedef int (*foo)(void) __stdcall;|. Of course, MSVC barfs on that syntax. So, we have another set of fugly macros for nscore.h. Each platform needs to define NS_STDCALL to __stdcall or empty. Then we have: #ifdef __GNUC__ #define NS_STDCALL_FUNCPROTO(x,y) (x) y NS_STDCALL #else NS_STDCALL_FUNCPROTO(x,y) (NS_STDCALL x) y #endif Then: typedef nsresult NS_STDCALL_FUNCPROTO(nsISVGValueObserver::*SVGObserverNotifyFunction, (nsISVGValue*)); Oh, and when the function prototype uses a fully qualified class name, it needs to be inside the declaration of that class or gcc will barf.

Re: xptcall, Could we consolidate gcc x86 version XPTC_InvokeByIndex or does GCC's abi change between Unix, Linux, and Win32? Also would be nice to have some comments for the gnuc version of the assembler. I don't think the trailing \ are necessary in this context either. I'm not familiar with the notation below. Not sure if it's trying to define symbols or what, but none of these are referenced in the assembler. : "=d" (d) : "a" (paramCount) : "memory"

> Re: xptcall, Could we consolidate gcc x86 version XPTC_InvokeByIndex or does > GCC's abi change between Unix, Linux, and Win32? Not sure. I assumed that we separated win32 from the rest of the platforms for a reason. > I'm not familiar with the notation below. Not sure if it's trying to define > symbols or what, but none of these are referenced in the assembler. http://www-106.ibm.com/developerworks/linux/library/l-ia.html?dwzone=linux > : "=d" (d) This is the set of output registers. We're telling it to stick the results from %edx into the d variable. > : "a" (paramCount) This is the set of input registers. It's assigning the value of paramCount to %eax. > : "memory" This is the set of clobber registers or registers for asm to avoid using internally because they will be clobbered.

Comment on attachment 116374 [details] [diff] [review] rdf changes hrmm. I liked the old method.. this really doesn't work on gcc? I swear PR_CALLBACK should work here.

Taking what we learned about __stdcall from NS_STDCALL_FUNCPROTO, we can simplify the rdf changes. It works in my depend msvc & mingw builds. I haven't tried a clobber yet.

Comment on attachment 116459 [details] [diff] [review] rdf changes v1.2 (checked in) hey, I'm cool with that. Any chance we can also add a "static const" to the front of ContainerInfo?

gcc warns & msvc errors if |static const| is added before the gContainerInfo definition: "invalid conversion from 'const RDFContentSinkImpl::ContainerInfo*' to 'RDFContentSinkImpl::ContainerInfo*' on the line with the for loop. Just |static| works though.

(What if you change the for loop to "for (const ContainerInfo* ..."?)