134113 - make mozilla build on win32 using GCC

Status: RESOLVED FIXED

(SeaMonkey :: Build Config, enhancement)

Description

[Jonathan Wilson]

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.

Comment 1

[Jonathan Wilson]

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.

Comment 2

[Christian :Biesinger (don't email me, ping me on IRC)]

interestingly this is not a duplicate

confirming

Comment 3

[Christian :Biesinger (don't email me, ping me on IRC)]

oh, btw, bug 62773 is related

Comment 4

[Jonathan Wilson]

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)

Comment 5

[Jonathan Wilson]

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.

Comment 6

[Christian :Biesinger (don't email me, ping me on IRC)]

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.

Comment 7

[Jonathan Wilson]

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

Comment 8

[Jonathan Wilson]

Attachment: first round of changes to nsprpub build system

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)

Comment 9

[Jonathan Wilson]

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?

Comment 10

[sobotka]

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.

Comment 11

[Jonathan Wilson]

Attachment: patch v2

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

Comment 12

[sobotka]

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

Comment 13

[Jonathan Wilson]

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 14

[cls]

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()?

Comment 15

[Jonathan Wilson]

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.

Comment 16

[cls]

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.

Comment 17

[Jonathan Wilson]

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)

Comment 18

[Jonathan Wilson]

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

Comment 19

[Jonathan Wilson]

Attachment: patch v3

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

Comment 20

[sobotka]

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.

Comment 21

[Jonathan Wilson]

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.

Comment 22

[Jonathan Wilson]

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.

Comment 23

[Jonathan Wilson]

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.

Comment 24

[Jonathan Wilson]

Attachment: patch v4

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

Comment 25

[Christian :Biesinger (don't email me, ping me on IRC)]

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

Comment 26

[Christian :Biesinger (don't email me, ping me on IRC)]

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

Comment 27

[Jonathan Wilson]

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

Comment 28

[Jonathan Wilson]

Attachment: patch v5

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 29

[cls]

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?

Comment 30

[Jonathan Wilson]

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.

Comment 31

[cls]

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

Comment 32

[hacker formerly known as [e-mail]]

Attachment: mingw gcc patch v1

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.

Comment 33

[Christian :Biesinger (don't email me, ping me on IRC)]

 # 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 34

[Jonathan Wilson]

Comment on attachment 79133 [details] [diff] [review]
patch v5

Marking obsolete since seawoods idea of using mingw makes more sense

Comment 35

[Jonathan Wilson]

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.

Comment 36

[Jonathan Wilson]

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)

Comment 37

[Jonathan Wilson]

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.

Comment 38

[sobotka]

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.

Comment 39

[Jonathan Wilson]

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

Comment 40

[sobotka]

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

Comment 41

[hacker formerly known as [e-mail]]

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

Comment 42

[Jonathan Wilson]

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)

Comment 43

[hacker formerly known as [e-mail]]

Attachment: mingw gcc patch v2

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.

Comment 44

[Jonathan Wilson]

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?

Comment 45

[Jonathan Wilson]

Attachment: beginnings of a patch for main mozilla tree build configs

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.

Comment 46

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Attachment: some changes dbaron was working on

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.

Comment 47

[Jonathan Wilson]

Attachment: new patch for main moz tree

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

Comment 48

[Christian :Biesinger (don't email me, ping me on IRC)]

+
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??

Comment 49

[Jonathan Wilson]

Attachment: new patch

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?

Comment 50

[timeless]

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.

Comment 51

[Jonathan Wilson]

Attachment: current patch

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

Comment 52

[Jonathan Wilson]

Attachment: same patch I posted earlier but updated to the latest trunk

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

Comment 53

[Jonathan Wilson]

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

Comment 54

[Jonathan Wilson]

Attachment: patch including the fix for 137059

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

Comment 55

[Shotaro Kamio]

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

Comment 56

[Jonathan Wilson]

No, the patches arent anywhere near finished.

Comment 57

[hacker formerly known as [e-mail]]

Attachment: NSPR mingw gcc v3 patch

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.

Comment 58

[cls]

Attachment: moz mingw v6 patch

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

Comment 59

[Jonathan Wilson]

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.

Comment 60

[cls]

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.

Comment 61

[Daniel Veditz [:dveditz]]

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.

Comment 62

[cls]

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.

Comment 63

[Brendan Eich [:brendan]]

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

Comment 64

[Daniel Veditz [:dveditz]]

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.

Comment 65

[Jonathan Wilson]

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?

Comment 66

[cls]

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.

Comment 67

[Jonathan Wilson]

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

Comment 68

[Jonadab the Unsightly One (Nathan Eady)]

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

Comment 69

[Alfonso Martinez]

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

Comment 70

[Damian Yerrick]

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.

Comment 71

[Jonathan Wilson]

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.

Comment 72

[cls]

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) [e-mail] 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.

Comment 73

[Jonathan Wilson]

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.

Comment 74

[Jonathan Wilson]

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

Comment 75

[Jonathan Wilson]

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)

Comment 76

[Olivier Mengué]

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.

Comment 77

[Dimitrie O. Paun]

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.

Comment 78

[Marc Rubin]

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. 

Comment 79

[cls]

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.

Comment 80

[Dimitrie O. Paun]

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?

Comment 81

[cls]

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.

Comment 82

[Dimitrie O. Paun]

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>

Comment 83

[hacker formerly known as [e-mail]]

Attachment: NSPR mingw gcc3 v1.0

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.

Comment 84

[Dimitrie O. Paun]

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? 

Comment 85

[cls]

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.

Comment 86

[cls]

Attachment: nobrainer build changes v1.0

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 87

[Dan Mosedale (:dmosedale, :dmose)]

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

r=dmose

Comment 88

[Dimitrie O. Paun]

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

Comment 89

[cls]

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.

Comment 90

[Dimitrie O. Paun]

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

Comment 91

[cls]

Attachment: straight code changes v1.0

Comment 92

[cls]

Attachment: rest of gcc3 changes v1.0

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

Comment 93

[Christian :Biesinger (don't email me, ping me on IRC)]

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

Comment 94

[Christian :Biesinger (don't email me, ping me on IRC)]

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

Comment 95

[David G King]

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.

Comment 96

[David Fraser]

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

Comment 97

[Dimitrie O. Paun]

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.

Comment 98

[Wan-Teh Chang]

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

Comment 99

[David G King]

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.

Comment 100

[cls]

Attachment: NSPR mingw gcc v1.1

* 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

Comment 101

[Dimitrie O. Paun]

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?

Comment 102

[cls]

Attachment: test logfile

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.

Comment 103

[cls]

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.

Comment 104

[Dimitrie O. Paun]

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.

Comment 105

[Dimitrie O. Paun]

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?

Comment 106

[Frederic Bezies]

Does checkin in the early morning yesterday break calendar building ?

Cf bug 187663 I filled this morning.

Comment 107

[Wan-Teh Chang]

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?

Comment 108

[cls]

Attachment: NSPR mingw gcc3 v1.2

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.

Comment 109

[cls]

Attachment: moz mingw gcc3 v1.1

* 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

Comment 110

[Jonathan Wilson]

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.

Comment 111

[Dan Mosedale (:dmosedale, :dmose)]

Attachment: NSPR ming gcc3 v1.3

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?

Comment 112

[Dan Mosedale (:dmosedale, :dmose)]

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.

Comment 113

[Dan Mosedale (:dmosedale, :dmose)]

Attachment: NSPR mingw gcc3 patch v1.4

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

Comment 114

[Dan Mosedale (:dmosedale, :dmose)]

Attachment: moz mingw gcc3 patch, v1.2

* 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 115

[Wan-Teh Chang]

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?

Comment 116

[cls]

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.

Comment 117

[hacker formerly known as [e-mail]]

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. 

Comment 118

[Dan Mosedale (:dmosedale, :dmose)]

Attachment: moz mingw gcc 3 patch, v1.3

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.

Comment 119

[Dan Mosedale (:dmosedale, :dmose)]

Attachment: moz mingw gcc3 patch, v1.4

* 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 120

[Dan Mosedale (:dmosedale, :dmose)]

Comment on attachment 111925 [details] [diff] [review]
moz mingw gcc3 patch, v1.4

Whoops, attached the wrong file.

Comment 121

[Wan-Teh Chang]

Attachment: NSPR mingw gcc3 patch v1.5

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.

Comment 122

[Dan Mosedale (:dmosedale, :dmose)]

Attachment: moz mingw gcc3 patch v1.5

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.

Comment 123

[Christian :Biesinger (don't email me, ping me on IRC)]

+ifndef GNU_CC
 ifndef NO_MFC

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

Comment 124

[Dan Mosedale (:dmosedale, :dmose)]

Attachment: moz mingw gcc3 patch v1.6

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 125

[Wan-Teh Chang]

Comment on attachment 111962 [details] [diff] [review]
NSPR mingw gcc3 patch v1.5

I've checked in this NSPR patch.

Comment 126

[alanjstr]

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

Comment 127

[cls]

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.

Comment 128

[cls]

Attachment: NSS mingw patch v1.1

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.

Comment 129

[Wan-Teh Chang]

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

Comment 130

[Chris Neale]

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 131

[Dan Mosedale (:dmosedale, :dmose)]

Comment on attachment 111962 [details] [diff] [review]
NSPR mingw gcc3 patch v1.5

Marking obsolete since this has been checked in.

Comment 132

[Dan Mosedale (:dmosedale, :dmose)]

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

Comment 133

[Chris Neale]

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 ?

Comment 134

[Chris Neale]

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

Comment 135

[Chris Neale]

not quite bugspam:

what .mozconfig options / ./configure options are successful builders building
with ?

Comment 136

[Chris Neale]

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 ?

Comment 137

[cls]

Attachment: NSS test results.html

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?

Comment 138

[cls]

Attachment: NSS mingw patch v1.2

Changes to get NSS tests running.

Comment 139

[cls]

Attachment: NSS mingw patch v1.3

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.

Comment 140

[cls]

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.

Comment 141

[Dan Mosedale (:dmosedale, :dmose)]

Attachment: moz ming gcc3 patch v1.7

* 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"

Comment 142

[cls]

Attachment: LDAP mingw patch v1.0 (checked in)

Comment 143

[cls]

Attachment: moz mingw gcc3 v1.8

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

Comment 144

[cls]

Attachment: NSS mingw patch v1.4

Just removing the diff cruft added by $Id$

Comment 145

[cls]

Attachment: moz mingw gcc3 patch v1.9

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

Comment 146

[cls]

Let's get this party started...

Comment 147

[cls]

Attachment: central makefile changes (checked in)

Comment 148

[cls]

Attachment: other makefile changes (checked in)

Comment 149

[cls]

Attachment: xptcall changes

Comment 150

[cls]

Attachment: rdf changes

Comment 151

[cls]

Attachment: msg protocol changes (checked in)

Comment 152

[Jonathan Wilson]

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?

Comment 153

[cls]

Attachment: cleanup of XP code

Comment 154

[cls]

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

Comment 155

[(not reading, please use [e-mail] instead)]

Comment on attachment 116377 [details] [diff] [review]
msg protocol changes (checked in)

if that works, sr=sspitzer

Comment 156

[cls]

Attachment: mingw specific code changes

Comment 157

[cls]

Attachment: resource changes

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 158

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

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 159

[Dan Mosedale (:dmosedale, :dmose)]

Comment on attachment 114294 [details] [diff] [review]
LDAP mingw patch v1.0 (checked in)

sr=dmose for the client ldap branch

Comment 160

[cls]

Attachment: configure.in changes (checked in)

Comment 161

[Marc Rubin]

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! 

Comment 162

[Brant Gurganus]

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 163

[cls]

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.

Comment 164

[David Bradley]

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"

Comment 165

[cls]

> 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 166

[Alec Flett]

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.

Comment 167

[cls]

Attachment: xp code changes v1.2 (checked in)

Comment 168

[cls]

Attachment: rdf changes v1.2 (checked in)

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 169

[Alec Flett]

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?

Comment 170

[cls]

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.

Comment 171

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

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

Comment 172

[David Bradley]

There's functions that take non-const versions. But I think it would be worth
exploring if it ripple effect isn't too great. If nothing else to make sure
things that shouldn't be modifying this array aren't.

Comment 173

[cls]

Addind const in both places works.

Comment 174

[Alec Flett]

Comment on attachment 116459 [details] [diff] [review]
rdf changes v1.2 (checked in)

awesome, great to hear the const stuff worked.

beyond syntactic advantages, const is also good because it puts the data in a
read-only section of the DLL, which allows it to be more easily shared between
processes, etc..
sr=alecf with const in both places.

Comment 175

[Doug Turner (:dougt)]

Comment on attachment 116453 [details] [diff] [review]
xp code changes v1.2 (checked in)

changes like this, cant be right - can they??

-void		   *NS_GlobalReAlloc(HGLOBAL hgMemory,
+void		   *NS_GlobalReAlloc(HGLOBAL *hgMemory,

Comment 176

[cls]

Yep, "conflicting types for 'NS_GlobalReAlloc'". Compare
http://lxr.mozilla.org/seamonkey/source/xpinstall/wizard/windows/setup/extra.c#175
to 
http://lxr.mozilla.org/seamonkey/source/xpinstall/wizard/windows/setup/extra.h#35
. I don't know how msvc compiles that without an error.

Comment 177

[cls]

Attachment: xptcall changes v1.3 (checked in)

Here are the changes to make xptcall reuse the xptcinvoke_gcc_x86
implementation.   One key change was to add the SYMBOL_UNDERSCORE macro so that
the inline asm can generate function names with the leading underscore as gcc
expects (e.g, _XPTC_InvokeByIndex instead of XPTC_InvokeByIndex).

Note that this patch does not use the xptcstubs_gcc_x86 implementation.  I
managed to get stubs_gcc compiled and libxpcom linked but that combination
fails when linking libxpconnect.  The linker complains that it cannot find
symbol _ZN14nsXPTCStubBase7Stub(#n)Ev@4.  That function is available in
libxpcom except that the function has an additional underscore.  But if I
remove the additional underscore added by SYMBOL_UNDERSCORE, libxpcom.dll won't
link.  I suspect that adding the underscore is the proper thing to do and the
xpconnect problem is a bug with the linker exporting the wrong symbols.

Comment 178

[Mark Smith [:mcs]]

Comment on attachment 114294 [details] [diff] [review]
LDAP mingw patch v1.0 (checked in)

The LDAP changes look OK.

Comment 179

[cls]

Comment on attachment 114294 [details] [diff] [review]
LDAP mingw patch v1.0 (checked in)

The ldap changes have been checked into the ldap trunk & the client branch.

Comment 180

[Brendan Eich [:brendan]]

Comment on attachment 116381 [details] [diff] [review]
mingw specific code changes

If this all works with and without __MINGW32__ defined, I'm ok with it, but I
can't r= for module owners, esp. for those who know Windows better than I do. 
And maybe ssu or someone cares about the L_ prefixes you put on the HKEY_
macros that collided?  Dunno.

rubbery r=me, so long as this patch works when compiled both with and without
mingw32.

dmose was just suggesting that some of these #if's are over-narrow -- that
cygwin in addition to mingw32 would just work if you used __GNUC__ && XP_WIN or
vice versa.  I'll leave it to him to make that case.

/be

Comment 181

[cls]

Comment on attachment 116381 [details] [diff] [review]
mingw specific code changes

I guess I should break out those changes. 

Cygwin gcc uses the mingw w32api and the mingw defines when building with
-mno-cygwin so the current ifdefs should work fine.  We don't support building
for the cygwin posix runtime env which is what uses the __CYGWIN__ ifdefs.

Comment 182

[Bradley Baetz (:bbaetz)]

Comment on attachment 116389 [details] [diff] [review]
configure.in changes (checked in)


This looks reasonable. I can't test, but theres a tinderbox successfully
running with these, so r=bbaetz

Comment 183

[Frederic Bezies]

Just a question : I have big building problems today. Having grabbed the latest
tarball available and adding to it all CVS patches until today 00:45, every time
I launch build process, I have this :

"configure:error: Building crypto support requires a valid version of the
standalone assembler, ml.exe"

Of course, it worked yesterday before big patches for this bug...

Sorry for spamming this bug, but I am a little upset after seeing this bug 2 or
3 times :-/

Comment 184

[cls]

Attachment: gfx-widget-viewer changes

Comment 185

[cls]

Attachment: imglib changes

Comment 186

[cls]

Attachment: sun-java changes (checked in)

Comment 187

[cls]

Attachment: js changes

Comment 188

[cls]

Attachment: layout - mailnews changes

Comment 189

[cls]

Attachment: nsWindowsHooksUtil change

Comment 190

[cls]

Attachment: necko changes

Comment 191

[cls]

Attachment: plugin changes

Comment 192

[cls]

Attachment: remaining xpcom changes

Comment 193

[cls]

Attachment: xpinstall changes

Comment 194

[cls]

Comment on attachment 116679 [details] [diff] [review]
js changes

Transferring brendan's r= for the js changes.

Comment 195

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Comment on attachment 116684 [details] [diff] [review]
plugin changes

sr=dbaron, although I wonder if it would be a good idea to mark all features
that you've disabled for __MINGW32__ with some special comment so you can find
them easily.

(Also, why are we including "afxres.h" rather than <afxres.h>?	Would making
that change have fixed the problem for gcc?)

Comment 196

[timeless]

Comment on attachment 116679 [details] [diff] [review]
js changes

>Index: js/src/jstypes.h
>@@ -83,6 +83,12 @@
> **
> ***********************************************************************/
> #ifdef WIN32
>+
>+#if defined(__GNUC__)
>+#undef _declspec
>+#define _declspec(x) __declspec(x)
>+#endif
>+
> /* These also work for __MWERKS__ */
> #define JS_EXTERN_API(__type) extern __declspec(dllexport) __type
> #define JS_EXPORT_API(__type) __declspec(dllexport) __type

is this change needed? js no longer uses _declspec

Comment 197

[timeless]

Comment on attachment 116682 [details] [diff] [review]
nsWindowsHooksUtil change

>Index: xpfe/components/winhooks/nsWindowsHooksUtil.cpp
>@@ -339,7 +339,8 @@
>         rv = RegistryEntry::set();
>         if ( NS_SUCCEEDED( rv ) ) {
>             // Save old.
>-            RegistryEntry( HKEY_LOCAL_MACHINE, "Software\\Mozilla\\Desktop", fullName().get(), prev.get() ).set();
>+            RegistryEntry tmp( HKEY_LOCAL_MACHINE, "Software\\Mozilla\\Desktop", fullName().get(), prev.get() );
>+           tmp.set();
indentation is wrong

>@@ -373,20 +374,20 @@
>             // comes from nsINativeAppSupportWin.h.
>             char buffer[ _MAX_PATH + 8 ]; // Path, plus '@', comma, minus, and digits (5)
>             _snprintf( buffer, sizeof buffer, "@%s,-%d", thisApplication().get(), IDS_STARTMENU_APPNAME );
>-            RegistryEntry( HKEY_LOCAL_MACHINE, 
>+            RegistryEntry tmp_entry1( HKEY_LOCAL_MACHINE, 
>                            subkey.get(),
>                            "LocalizedString", 
>-                           buffer ).set();
>+                           buffer ); tmp_entry1.set();
here you put the .set() on the same line as the last bit of the object

>@@ -398,15 +399,17 @@
>                                                        getter_AddRefs( bundle ) ) ) &&
>                  NS_SUCCEEDED( bundle->GetStringFromName( NS_LITERAL_STRING( "prefsLabel" ).get(), getter_Copies( label ) ) ) ) {
>                 // Set the label that will appear in the start menu context menu.
>-                RegistryEntry( HKEY_LOCAL_MACHINE,
>+                RegistryEntry tmp_entry4( HKEY_LOCAL_MACHINE,
>                                nsCAutoString( subkey + NS_LITERAL_CSTRING( "\\shell\\properties" ) ).get(),
>                                "", 
>-                               NS_ConvertUCS2toUTF8( label ).get() ).set();
>+                               NS_ConvertUCS2toUTF8( label ).get() );
>+                tmp_entry4.set();
here you don't

Comment 198

[timeless]

Comment on attachment 116684 [details] [diff] [review]
plugin changes

>Index: modules/plugin/tools/sdk/samples/basic/windows/basic.rc
>@@ -7,7 +7,11 @@
> //
> // Generated from the TEXTINCLUDE 2 resource.
> //
>+#ifdef __MINGW32__
>+#include <windows.h>
>+#else
> #include "afxres.h"
>+#endif

please make the change unconditionally (for each occurence)

>Index: modules/plugin/tools/sdk/samples/scriptable/windows/npscriptable.rc
>Index: modules/plugin/tools/sdk/samples/simple/npsimple.rc
>Index: modules/plugin/tools/sdk/samples/winless/windows/npwinless.rc

Comment 199

[timeless]

Comment on attachment 116686 [details] [diff] [review]
xpinstall changes

(this looks like someone tripped over the HKEY_s as #define's)
could we use NS_ instead of L_?
(i'd love to mark r+)

Comment 200

[Dimitrie O. Paun]

Should this:  >+#ifdef __MINGW32__ >+#include <windows.h> >+#else > #include "afxres.h" >+#endif  just be:  #include <winresrc.h>  ? 

Comment 201

[Brendan Eich [:brendan]]

Comment on attachment 116679 [details] [diff] [review]
js changes

Please address timeless's comments -- I was out of date on _declspec details.

/be

Comment 202

[:deanis74]

Comment on attachment 116685 [details] [diff] [review]
remaining xpcom changes

>-#if defined(XP_WIN32) || defined(XP_OS2)
>+#if defined(XP_WIN32) && defined(__GNUC__)
>+
>+#define XPCOM_DLL         "libxpcom" MOZ_DLL_SUFFIX
>+#define XPCOM_SEARCH_KEY  "PATH"
>+#define GRE_CONF_NAME     "gre.config"
>+#define GRE_WIN_REG_LOC   "Software\\mozilla.org\\GRE\\"
>+
>+#elif defined(XP_WIN32) || defined(XP_OS2)

This seems cleaner to me, since there's no duplication of #defines.

#if defined(XP_WIN32) || defined(XP_OS2)

#if defined(XP_WIN32) && defined(__GNUC__)
#define XPCOM_DLL	  "libxpcom" MOZ_DLL_SUFFIX
#else
#define XPCOM_DLL	  "xpcom.dll"
#endif

#define XPCOM_SEARCH_KEY  "PATH"
#define GRE_CONF_NAME	  "gre.config"
#define GRE_WIN_REG_LOC   "Software\\mozilla.org\\GRE\\"

#endif

Comment 203

[Christian :Biesinger (don't email me, ping me on IRC)]

isn't this:
#if defined(XP_WIN32) || defined(XP_OS2)
equivalent to:
#ifdef XP_PC
?

Comment 204

[cls]

> is this change needed? js no longer uses _declspec

_declspec isn't defined by gcc and those macros are still used by liveconnect.

> please make the change unconditionally (for each occurence)

I'm waiting for some win32 programmer to say that there's not going to be a
problem with windows.h pulling in a bunch of extra junk on MSVC builds.  mingw
w32api doesn't have afxres.h and the headers are cleaner overall so it's a bit
less of a concern there.

> could we use NS_ instead of L_?

Fine by me.  ssu still needs to sign off on the change though.

> Should this: ..... just be:  #include <winresrc.h>  ?

Dunno. I missed that msvc had <winresrc.h> when I first made the changes.  Does
msvc's <winresrc.h> include the defines used by <afxres.h> ?

> isn't this:
> #if defined(XP_WIN32) || defined(XP_OS2)
> equivalent to:
> #ifdef XP_PC

Yes, but XP_PC is deprecated (bug 56767).

Comment 205

[Darin Fisher]

Comment on attachment 116683 [details] [diff] [review]
necko changes

>Index: netwerk/base/src/nsNativeConnectionHelper.cpp

>+#ifndef __MINGW32__
> #include "nsAutodialWin.h"
>+#endif

are the RAS header files not available somehow?


>Index: netwerk/dns/src/nsDnsService.cpp

>+#ifndef __GNUC__
>+    static
>+#endif

hmm... does MSVC really need |static|?


>+#ifndef __GNUC__
>+static 
>+#endif

i think you still want the function to have |static| linkage.  GCC
shouldn't have a problem with this.  if necessary, forget trying
to make this function access private members.  just decl the members
public... and add a comment.  they would only be public to code in
the same source file, so it's not like decl'ing them private gains
us much ;-)

would love to avoid this conditional code if possible.

Comment 206

[cls]

> are the RAS header files not available somehow?

Specifically, mingw doesn't have <rasdlg.h> or the LPRASPBDLG & LPRASDIALDLG
types.  The earlier patches just disabled the bits that called the dialogs.  I
later thought it would be better to just disable the entire autodial code since
it seems to require the RAS dialogs.

>>Index: netwerk/dns/src/nsDnsService.cpp

> i think you still want the function to have |static| linkage.  GCC
> shouldn't have a problem with this. 

c:/root/mozilla/netwerk/dns/src/nsDnsService.h:159 storage class specifiers
invalid in friend function declarations.

>if necessary, forget trying
> to make this function access private members. just decl the members
> public... and add a comment.

ok.

Comment 207

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

> > i think you still want the function to have |static| linkage.  GCC
> > shouldn't have a problem with this. 
> 
> c:/root/mozilla/netwerk/dns/src/nsDnsService.h:159 storage class specifiers
> invalid in friend function declarations.

Try forward-declaring the function before the class declaration (with |static|),
and then removing the |static| from the friend declarations?

Comment 208

[Stuart Parmenter]

Comment on attachment 116677 [details] [diff] [review]
imglib changes

"ew"  I'm not r='ing a patch that causes windows.h to get included in here.

Comment 209

[Doug Turner (:dougt)]

Comment on attachment 116685 [details] [diff] [review]
remaining xpcom changes

okay.

Comment 210

[cls]

Attachment: imglib changes v1.1

Comment 211

[timeless]

note that msvc doesn't have to have mfc either, my msvc6 doesn't, although my
Digital Mars and Borland C build envs do.

a few interesting urls..
http://doc.ddart.net/msdn/header/include/winres.h.html
http://sources.redhat.com/ml/cygwin/2000-08/msg00267.html

in the case of the plugins rc files IDC_STATIC isn't used so winresrc.h is fine.

Also, when you change afxres to something else, please change 
2 TEXTINCLUDE DISCARDABLE 
BEGIN
     "#include ""afxres.h""\r\n"
                 ^this, otherwise msvc will reincarnate the line.

cls: i don't see _declspec anywhere in liveconnect. note that i flagged this
specific item because i recently replaced _declspec with __declspec in spidermonkey.

Comment 212

[Boris Zbarsky [:bzbarsky]]

Comment on attachment 116680 [details] [diff] [review]
layout - mailnews changes

This looks ok, modulo the issue that pavlov raised about windows.h (and my
inability to evaluate the upsides or downsides of its inclusion, since I have
no idea what lives in it).  So pav, why are you against including windows.h?

Comment 213

[cls]

> cls: i don't see _declspec anywhere in liveconnect. note that i flagged this
> specific item because i recently replaced _declspec with __declspec in
spidermonkey.

I thought that you meant that you removed the use of the JS_EXTERN_API,
JS_EXPORT_API, etc flags from js which used the _declspec declaration.  If you
just did a search-n-replace, then you're right, that extra #define isn't needed.

Comment 214

[cls]

Attachment: js changes v1.1

Comment 215

[Peter Lubczynski]

Comment on attachment 116684 [details] [diff] [review]
plugin changes

Do the default plugin's resources need these changes too?

Comment 216

[David Bradley]

Comment on attachment 116533 [details] [diff] [review]
xptcall changes v1.3 (checked in)


r=dbradley

If this works ok and passes the tests for mingw, I say go ahead and we can look
at clean up issues later.

Comment 217

[cls]

Comment on attachment 116533 [details] [diff] [review]
xptcall changes v1.3 (checked in)


Checked in xptcall changes minus unused xptcstubs_gcc_x86_unix.cpp changes.

Comment 218

[cls]

Attachment: remaining xpcom changes v1.1

With dean's suggested changes.

Comment 219

[cls]

Attachment: plugin changes v2.0 (checked in)

*sigh* merged the wrong set of changes.

Comment 220

[Brendan Eich [:brendan]]

Comment on attachment 116763 [details] [diff] [review]
js changes v1.1

I'd rather not nest a <sys/types.h> include in jstypes.h -- can't you change
the #elif defined(WIN32) to exclude the __MINGW32__ case, so it falls into the
#else clause that uses long long?

/be

Comment 221

[cls]

Attachment: js changes v1.2 (checked in)

Comment 222

[Brendan Eich [:brendan]]

Comment on attachment 116799 [details] [diff] [review]
js changes v1.2 (checked in)

r=[e-mail], all you need for js/src/*.[ch] changes.	Thanks to
timeless for watching my back ;-).

/be

Comment 223

[cls]

Attachment: xpinstall changes v1.1 (checked in)

Comment 224

[Dimitrie O. Paun]

This may need a configure test -- what happens when they add it to their 
headers? 
 
+// _mbsstr isn't declared in w32api headers but it's there in the libs 
+#ifdef __MINGW32__ 
+extern "C" { 
+unsigned char *_mbsstr( const unsigned char *str, 
+                        const unsigned char *substr ); 
+}; 
+#endif 
 

Comment 225

[David Fraser]

I saw that the mingw port needs a rasdlg.h header, which mingw didn't have
(comment 206). I asked on the mingw-users list and Danny Smith has just added
this to CVS, so it should be in the next version of mingw (email below)

 --- Danny Smith <[e-mail]> wrote: >  --- David Fraser
<[e-mail]> wrote: > Hi

>>> > 
>>> > This is from the effort to port Mozilla for Windows to gcc using mingw.
>>> > One of the issues is the lack of a rasdlg.h header. What is the best way 
>>> > to go about adding such a header?
>>> > 
>
>> 
>> Snap! I have halfway-house version of rasdlg.h somewhere in archive because I
>> needed it for an old project too.  I'll look for it and try to get it into
>> CVS
>> and then you can tell me what's missing.
>> 
>> Danny


My version has been committed.  If you need help with converting def file to
lib, please post privatey. See:

http://cygwin.com/ml/cygwin-cvs/2003-q1/msg00348.html

Danny

Comment 226

[Bradley Baetz (:bbaetz)]

Comment on attachment 116683 [details] [diff] [review]
necko changes

So, why do you need the friend? It doesn't make sense - you have a function,
right? the function is part of the class even those its static, and is thus
able to access private members automatically (assuming, of course, that it can
get an instance of the class somehow). Keep the static, and lose the |friend|
for everyone.  Or does msvc not like that?

Comment 227

[David G King]

I'm getting an error with 
sh /cygdrive/c/mozilla/source/mozilla/build/cygwin-wrapper windres -O coff -DOST
YPE=\"WINNT5.1\" -DOSARCH=\"WINNT\" -DOJI --include-dir ../../dist/include/dbm -
-include-dir ../../dist/include --include-dir ../../dist/include/nspr -o module.
res module.rc
c:\gnu\mingw\bin\windres.exe: module.rc:56: parse error

module.rc lives in mozilla/dbm/tests

My environment is setup as per comment #145.

I'm not sure what DBM is, however I'm more curius about why it's compiling the
tests dir as my configure file has --disable-tests.

Is this a bug due to moving from MSVC to GCC, or should I file a new bug on this?

Comment 228

[cls]

dpaun: I'm torn about the need for a configure test there.  At some point,
whenever the missing features get added, we're most likely going to bump the
minimum required version of the w32api/mingw-runtime just like we did for the
compiler.  I'm not seeing a real need to support those older versions by adding
a configure test.  So, when/if it gets added, the build will break, we'll fix it
and bump the version.

davidf: I saw that.  Very cool.  Thanks.  Now we'll just sit wondering when the
next release is. :)

bbaetz: No idea. 'friend' pre-dates the patch.

dgk: Can you provide a more complete log?  module.rc is generated whenever a
shared library (and I think an executable) is built.  It contains the version
info that shows up in the properties dialog.  When you 'moved', did you do a
'make distclean' to remove all traces of the msvc build?

Comment 229

[Robert John Churchill]

Comment on attachment 116459 [details] [diff] [review]
rdf changes v1.2 (checked in)

r=rjc

Comment 230

[cls]

Attachment: remaining xpcom changes v1.2 (checked in)

Pavlov explained his dislike of the <windows.h> changes.  The header pretty
much includes everything under the sun which includes a lot of stuff that we
don't need.  He also pointed out that there's probably some base header which
is including that file unnecessarily and causing the LoadImage/CreateImage
conflicts I saw.  That header is plevent.h.  It contains some mingw changes
that were made to NSPR back in 1999 and then the header was moved into XPCOM in
2000.

Comment 231

[cls]

Attachment: jpeg changes (checked in)

Comment 232

[cls]

Attachment: addrbook changes (checked in)

Comment 233

[cls]

Attachment: gfx-viewer changes v1.2 (checked in)

Comment 234

[cls]

Attachment: widget changes v1.2 (checked in)

Comment 235

[(not reading, please use [e-mail] instead)]

Comment on attachment 116927 [details] [diff] [review]
addrbook changes (checked in)

r/sr=sspitzer on the addrbook changes.

Comment 236

[jag (Peter Annema)]

Comment on attachment 116682 [details] [diff] [review]
nsWindowsHooksUtil change

r=jag, provided you move the |tmp_entry*.set()| calls to their own lines, and
you align |tmp.set()| in the first chunk with RegistryEntry.

Comment 237

[Doug Turner (:dougt)]

Comment on attachment 116924 [details] [diff] [review]
remaining xpcom changes v1.2 (checked in)

you can kill WIN16 if you like.

Comment 238

[cls]

Attachment: necko changes v1.1

Comment 239

[cls]

Attachment: win32 versioning fix for official builds (checked in)

Comment 240

[cls]

Attachment: necko changes v1.2 (checked in)

Comment 241

[Bradley Baetz (:bbaetz)]

Comment on attachment 116950 [details] [diff] [review]
necko changes v1.2 (checked in)


r=bbaetz. Did you try compiling w/o the friend? What error message do you get
from msvc?

Comment 242

[Christopher Blizzard (:blizzard)]

Comment on attachment 116928 [details] [diff] [review]
gfx-viewer changes v1.2 (checked in)


rs=blizzard

Comment 243

[Christopher Blizzard (:blizzard)]

Comment on attachment 116929 [details] [diff] [review]
widget changes v1.2 (checked in)


rs=blizzard

Comment 244

[cls]

bbaetz: Without the friend declaration, msvc complains about accessing private
members.

c:/root/mozilla/netwerk/dns/src/nsDnsService.cpp(1963) : error C2248: 'ProcessL
okup' : cannot access private member declared in class 'nsDNSService'
        c:/root/mozilla/netwerk/dns/src/nsDnsService.h(167) : see declaration o
 'ProcessLookup'

Comment 245

[Darin Fisher]

Comment on attachment 116950 [details] [diff] [review]
necko changes v1.2 (checked in)


sr=darin

Comment 246

[Aki Sasaki]

Comment on attachment 116949 [details] [diff] [review]
win32 versioning fix for official builds (checked in)


1.3.1 will show up as 1,3,0,0 in $productversion; is that intended?

Comment 247

[cls]

Per bug 180383, which added the build id to the product version, yes.

Comment 248

[Boris Zbarsky [:bzbarsky]]

Comment on attachment 116927 [details] [diff] [review]
addrbook changes (checked in)

Is this temporary till those components build with mingw?   Or will they never
do that?  Just add a comment saying which; r=bzbarsky.

Comment 249

[hacker formerly known as [e-mail]]

Comment on attachment 116927 [details] [diff] [review]
addrbook changes (checked in)

It's temporary until w32api includes LPADRBOOK & the various MAPI defines.

Comment 250

[Stuart Parmenter]

Comment on attachment 116925 [details] [diff] [review]
jpeg changes (checked in)

please add this to the changes file...

Comment 251

[Stuart Parmenter]

Comment on attachment 116928 [details] [diff] [review]
gfx-viewer changes v1.2 (checked in)


whats with the ifdef at the top of this patch?	using a UINT instead of a
PRUnichar?

Comment 252

[cls]

> whats with the ifdef at the top of this patch?	using a UINT instead of a
> PRUnichar?

Difference in implementation headers. msvc defines GCP_RESULTS->lpGlyphs as a
LPWSTR & w32api defines it as a UINT.  See the respective <wingdi.h> .  Neither
compiler likes it when I attempt to cast to the other type.

Comment 253

[Daniel Veditz [:dveditz]]

Comment on attachment 116828 [details] [diff] [review]
xpinstall changes v1.1 (checked in)


sr=dveditz

Comment 254

[Kevin McCluskey (gone)]

Comment on attachment 116929 [details] [diff] [review]
widget changes v1.2 (checked in)


r=[e-mail]

Comment 255

[Dimitrie O. Paun]

Folks,  This bug has grown to the point where it's very hard to follow what's going on.  AFAIKT, there are only 4 outstanding patches:    * resource changes    * sun-java changes    * nsWindowsHooksUtil change    * gfx-viewer changes v1.2 I guess my first question is if these are all that's left to close this bug.  Second, what's wrong with them? They all seem trivial enough, and fairly  uncontroversial.   

Comment 256

[Christian :Biesinger (don't email me, ping me on IRC)]

Dimitrie: The not yet checked in patches are awaiting review. please be a bit
more patient :)

Comment 257

[cls]

dpaun, the irony is that your post doesn't help.  See
http://www.mozilla.org.uk/temp/etiquette.html for pending bugzilla etiquette
guidelines.

What's going on is that patches are being reviewed and changes are being made
based upon those reviews.  Occasionally, I even have to explain why a patch does
what it does.  Standard development procedure.  Reviewers, as always, are
overloaded so reviews aren't instantaneous.  I will ping them manually if warranted.

There are five patches if you want crypto support and the build documentation
will also need to be updated. Btw, in case no one has noticed, the resources
patch causes the splash screen to stop working in msvc builds and it doesn't run
in the mingw builds.  I don't know what side-effects the change has on viewer.

Comment 258

[David G King]

While I haven't managed to build yet using gcc (due to configuration problems on
my machine, the latest being UNAME in MOZTOOLS), I'm really thankful for what
cls and the reviewers have done to get Mozilla to build with gcc on WIN32.

If anyone wants me to start the documentation/instructions based on the existing
WIN32 stuff and my experiences, just let me know.

Comment 259

[Stuart Parmenter]

Comment on attachment 116928 [details] [diff] [review]
gfx-viewer changes v1.2 (checked in)


r=pavlov

Comment 260

[Patrick C. Beard]

Comment on attachment 116678 [details] [diff] [review]
sun-java changes (checked in)

r=beard

Comment 261

[cls]

Attachment: resource changes v1.1 (checked in)

Here's the modified .rc changes which shouldn't have an adverse affect on msvc
builds (like no splash screen) but still allow mingw to build (still no splash
screen).  msvc rc.exe & mingw windres.exe seem to disagree on the type of the
first arg for controls.  I still have no idea why mingw can't load the dialog
either.  We may have to leave that as an auxillary bug.

http://www.cygwin.com/cygwin-ug-net/windres.html
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/tools/tools/dialog_resource.asp

Comment 262

[David G King]

Attachment: gcc on WIN32 docs v1.0

This is a first draft at some documentation on building Mozilla on WIN32 using
MinGW's gcc.

Any comments, suggestions, additions or changes are welcome.

I have yet to do any major work on the troubleshooting section, but that will
happen very soon.

CLS: If you want this in a seperate bug, as this one is getting rather busy,
let me know.

Comment 263

[cls]

Comment on attachment 117849 [details]
gcc on WIN32 docs v1.0

I don't see the need for having a completely separate build page for mingw. 
80% of that page is duplicated from the existing win32 page.  I'd rather
section off the compiler specific bits.  Also, since there is no Contributors
section on the existing win32 page (or any of the other platform build pages
that I know of), I don't think one needs to be added just for mingw.

Comment 264

[David G King]

Attachment: gcc on WIN32 docs 1.01

Make gcc instructions part of existing Win32 build instructions. I still need
to add Troubleshooting info, and tidy up the HTML.

Comment 265

[timeless]

Comment on attachment 117819 [details] [diff] [review]
resource changes v1.1 (checked in)


http://www.wotsit.org/download.asp?f=res32

per Marco Cocco based on microsoft documentation and based on my reading of the
msdn pages a resource compiler/decompiler needs to be able to handle both
strings and numeric types for the type and name fields, windres is therefore
broken.

borland resource workshop 4 (c) 1991, 1993 supported this.

you can checkin the changes if you like, but  i wouldn't.

Comment 266

[David G King]

On my system, I have the MinGW windres (2.13.90 20030104) and the cygwin windres
(2.13.90 20030308). I wonder if the cygwin version has the same problem as it is
a later build?

Comment 267

[Dimitrie O. Paun]

I'm afraid this is too ugly to live: 
 
-    CONTROL         108,IDC_STATIC,"Static",SS_BITMAP,11,11,83,162, 
+    CONTROL 
+#ifndef __MINGW32__ 
+                    108, 
+#endif 
+                    IDC_STATIC,"Static",SS_BITMAP,11,11,83,162, 
 
We're better off submitting a fix to windres, rather than working around it. 
Besides, I've just submitted a patch that would allow us to use -I for include 
dirs in windres: 
 
http://sources.redhat.com/ml/binutils/2003-03/msg00311.html 
 
so we can get rid of uglyass constructs such as these: 
 
+	$(RC) $(RCFLAGS) $(filter-out -U%,$(DEFINES)) 
$(INCLUDES:-I%=--include-dir %) $(OUTOPTION)$@ $< 
 
So yeah, it seems to me it makes sense to just submit some patches 
agains windres, and wait for a new release. Similarly for w32api 
headers. 
 
 

Comment 268

[cls]

Ok, waiting for the next release of windres almost definitely means missing the
next milestone release, which freezes at midnight PST on Tuesday.  Pushing out.

Comment 269

[Dimitrie O. Paun]

Folks, we have the following uglifying construct: 
 
ifdef GNU_CC 
	$(RC) $(RCFLAGS) $(filter-out -U%,$(DEFINES)) \ 
		$(INCLUDES:-I%=--include-dir %) $(OUTOPTION)$@ $< 
else 
	$(RC) $(RCFLAGS) -r $(DEFINES) $(INCLUDES) $(OUTOPTION)$@ $< 
endif 
 
As I mentioned already, I've already submitted a patch to windres 
(http://sources.redhat.com/ml/binutils/2003-03/msg00313.html) 
to accept -I for include dirs. Given that the windres maintainers 
like the idea, it's just a matter of time (few days, until I get 
the stupid FSF copyright assignment papers signed) until it goes in. 
 
Idealy, I'd like to completely remove the annoying ifdef. So what's 
left?  
 
First, the -r in the !GNU_CC case. This seems to be simply 
ignored by the MS rc, for backwards compatibility: 
 
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/tools/tools/using_rc_the_rc_command_line_.asp 
 
Do we _need_ to keep it around? 
 
Second, it seems that windres does not support the -U option. 
It should, and I'm considering submitting a patch to do just that. 
 
With that, the monster will collapse to simply: 
 
 	$(RC) $(RCFLAGS) $(DEFINES) $(INCLUDES) $(OUTOPTION)$@ $< 
 
which is so much easier on the eye. 
 
 

Comment 270

[Dimitrie O. Paun]

Folks, 
 
I've posted a message to the binutils guys regarding the windres bug: 
 
http://sources.redhat.com/ml/binutils/2003-03/msg00312.html 
 
Half an hour later I've got an untested patch back: 
 
http://sources.redhat.com/ml/binutils/2003-03/msg00317.html 
 
Anyone cares to give it a try so get this out of the way? 
 

Comment 271

[David G King]

OK, I've run out of ideas. I can get Mozilla to compile with MinGW's gcc after
manually applying the resource changes and the WindowsHooksUtil change. Lots of
warnings, but no errors. When I run it, it starts up and registers lots of
things, goes out to the network (ZoneAlarm tells me that), does some more
registering and then nothing, the application closes as does the terminal window.

Any ideas?

Comment 272

[cls]

Attachment: NSS mingw patch v1.5

Updated NSS changes from NSS 3.8 landing.

Comment 273

[David Fraser]

The latest win32 api released from mingw contains the updates for rasdlg.h
needed (see comment 206, comment 225) - the required file is w32api-2.3.tar.gz

Comment 274

[David G King]

The recent landing of NTLM has stuffed gcc builds in WIN32.

As far as I can tell it's to do with sspi.h and FreeCredentialHandle versus
FreeCredentialsHandle. MingW and cygwin have the extra "s", and I assume MSVC
doesn't.

Here is some of the last messages from my build.

c:/mozilla/source/mozilla/netwerk/protocol/http/src/nsHttpNTLMAuth.cpp: In
   destructor `virtual nsNTLMContinuationState::~nsNTLMContinuationState()':
c:/mozilla/source/mozilla/netwerk/protocol/http/src/nsHttpNTLMAuth.cpp:139: `
   struct _SECURITY_FUNCTION_TABLEA' has no member named `FreeCredentialHandle'
c:/mozilla/source/mozilla/netwerk/protocol/http/src/nsHttpNTLMAuth.cpp: In
   member function `virtual nsresult
   nsHttpNTLMAuth::GenerateCredentials(nsIHttpChannel*, const char*, const
   PRUnichar*, const PRUnichar*, const PRUnichar*, nsISupports**,
   nsISupports**, char**)':

Comment 275

[cls]

Attachment: Fix NTLM bustage (checked in)

Comment 276

[David G King]

I'm seeing a new problem now, this time with the module.rc files.

I'm getting lines like this -

  VALUE "FileVersion", "1.4a: 2003032821
"
  VALUE "ProductVersion", "1.4a: 2003032821
"

It's always the same lines, and using an editor to move the " to the end of the
previous line fixes the problem.

Here is an example of the messages I'm getting -

sh /cygdrive/c/mozilla/source/mozilla/build/cygwin-wrapper -up perl
c:/mozilla/source/mozilla/config/version_win.pl -QUIET 1 -DEPTH ../../../..
-TOPSRCDIR c:/mozilla/source/mozilla -BITS 32 -OBJDIR . -SRCDIR
c:/mozilla/source/mozilla/modules/libpr0n/decoders/mng -OFFICIAL 1 -DEBUG 1
-MODNAME imgmng Creating Resource file: module.res 
sh /cygdrive/c/mozilla/source/mozilla/build/cygwin-wrapper windres -O coff
-DOSTYPE=\"WINNT5.1\" -DOSARCH=\"WINNT\" --include-dir
../../../../dist/include/xpcom --include-dir ../../../../dist/include/gfx
--include-dir ../../../../dist/include/imglib2 --include-dir
../../../../dist/include/mng --include-dir ../../../../ dist/include/jpeg
--includedir ../../../../dist/include/zlib --include-dir
../../../../dist/include/imgmng --include-dir ../../../../dist/include
--include-dir ../../../../dist/include/nspr -o module.res module.rc
module.rc:71:34: warning: multi-line string literals are deprecated
module.rc:73:37: warning: multi-line string literals are deprecated
c:\gnu\mingw\bin\windres.exe: module.rc:71: parse error
make[5]: *** [module.res] Error 1
make[5]: Leaving directory
`/cygdrive/c/mozilla/source/mozilla/modules/libpr0n/decoders/mng'
make[4]: *** [libs] Error 2
make[4]: Leaving directory 
`/cygdrive/c/mozilla/source/mozilla/modules/libpr0n/decoders'
make[3]: *** [libs] Error 2
make[3]: Leaving directory 
`/cygdrive/c/mozilla/source/mozilla/modules/libpr0n'
make[2]: *** [tier_9] Error 2
make[2]: Leaving directory `/cygdrive/c/mozilla/source/mozilla'
make[1]: *** [default] Error 2
make[1]: Leaving directory `/cygdrive/c/mozilla/source/mozilla'
make: *** [build] Error 2

It seems a ^M has crept in somewhere.

CLS: Should I file a new bug on this, or can it be covered by this bug?

Comment 277

[Dimitrie O. Paun]

Folks, the windres breakage that was forcing us into extreme   
ugliness has just been fixed:  
   http://sources.redhat.com/ml/binutils-cvs/2003-03/msg00138.html  
  
My changes that will introduce -I, -r, -U are in the pipeline,   
waiting for FSF to aprove me as a contributor. I've sent the  
letter to them last week, so I expect it to be a matter of days  
until I get approved.  
 

Comment 278

[David G King]

Of course, to fix the problem in comment #276, is to remove BUILD-OFFICIAL and
MOZILLA-OFFICIAL from your environment. Besides setting the build date, I don't
think these do anything significant for personal debug use.

Comment 279

[cls]

Attachment: nsWindowsHooksUtil change v1.1 (checked in)

Updated with jag's changes.

Comment 280

[cls]

Comment on attachment 120044 [details] [diff] [review]
nsWindowsHooksUtil change v1.1 (checked in)

Transferring jag's r=.

Comment 281

[cls]

Comment on attachment 117869 [details]
gcc on WIN32 docs 1.01

Section 2.2 needs to be modified to make it clear that there is a choice of
compilers for win32.  As the second reads now, it makes it look like the mingw
tools are yet another build requirement.

Comment 282

[Darin Fisher]

Comment on attachment 118868 [details] [diff] [review]
Fix NTLM bustage (checked in)

r=darin

Comment 283

[David G King]

Attachment: gcc on WIN32 doc changes v1.1

Changes as requested. I hope I'm no longer too vague about compiler usage.

There have been some other changes/additions since the last update based on
experiences building with gcc.

Comment 284

[Mats]

Regarding attachment 118868 [details] [diff] [review]:
The link "http://www.mingw.org/download.shtml" really points to
http://sources.redhat.com/cygwin/download.html

Comment 285

[Mats]

Sorry for the spam. I mean Darin's
http://bugzilla.mozilla.org/attachment.cgi?id=120066&action=view
of course. Irony?

Comment 286

[cls]

Attachment: NSS mingw patch v1.6

Comment 287

[David G King]

OK, I've been having fun in gdb, using cygwin's version as it doesn't crash.
Note: Mozilla compiles without any errors, I just can't get it to startup.

When I run the program under gdb I get the following (note the C: in the Warning) :-

(gdb) run
The program being debugged has been started already.
Start it from the beginning? (y or n) y
Starting program: /cygdrive/c/mozilla/source/mozilla/dist/bin/mozilla.exe
Type Manifest File: c:\mozilla\source\mozilla\dist\bin\components\xpti.dat
+++ JavaScript debugging hooks installed. nsNativeComponentLoader:
autoregistering begins. nsNativeComponentLoader: autoregistering succeeded
nNCL: registering deferred (0) *** Chrome Registration of package:
Checking for contents.rdf at jar:resource:/chrome/comm.jar!/content/necko/
WARNING: Cannot tell if file:///C:/CYGDRIVE/C/WIND/TEMP is a directory or
file, file c:/mozilla/source/mozilla/netwerk/base/src/nsURLHelperWin.cpp,
line 88

Program received signal SIGSEGV, Segmentation fault.
0x01215abb in ?? ()




The "C:" is the problem, IMHO, so here is the stack trace. Any 
thoughts?

(gdb) bt
#0  net_GetURLSpecFromFile(nsIFile*, nsACString&) 
(aFile=0x11d5b80, result=@0x11cb340) at 
c:/mozilla/source/mozilla/netwerk/base/src/nsURLHelperWin.cpp:50
#1  0x6d763002 in 
nsFileProtocolHandler::GetURLSpecFromFile(nsIFile*, nsACString
&) (this=0x1205e50, file=0x11d5b80, result=@0x11cb340) at 
c:/mozilla/source/mozilla/netwerk/protocol/file/src/nsFileProtocolHandler
.cpp:173 #2  0x06d49917 in NS_GetURLSpecFromFile(nsIFile*, nsACString&,
nsIIOService*) (aFile=0x11d5b80, aUrl=@0x11cb340, ioService=0x0) at
../../../dist/include/necko/nsNetUtil.h:632 #3  0x06d3821f in
nsChromeRegistry::LoadInstallDataSource() (this=0x11cb318) at
c:/mozilla/source/mozilla/rdf/chrome/src/nsChromeRegistry.cpp:3186 #4 
0x06d38f22 in nsChromeRegistry::CheckForNewChrome() (this=0x11cb318) at
c:/mozilla/source/mozilla/rdf/chrome/src/nsChromeRegistry.cpp:3306 #5 
0x06d241c5 in nsChromeRegistry::Init() (this=0x11cb318) at
c:/mozilla/source/mozilla/rdf/chrome/src/nsChromeRegistry.cpp:396 #6 
0x06d211f0 in nsChromeRegistryConstructor(nsISupports*, nsID const&,
void**) (aOuter=0x0, aIID=@0x64128768, aResult=0x22f5d0) at
c:/mozilla/source/mozilla/rdf/chrome/build/nsChromeFactory.cpp:50 #7 
0x680330d3 in nsGenericFactory::CreateInstance(nsISupports*, nsID const&,
void**) (this=0x11e9650, aOuter=0x0,aIID=@0x64128768, aResult=0x22f5d0) at
c:/mozilla/source/mozilla/xpcom/glue/nsGenericFactory.cpp:86 #8 
0x67fe0d07 in nsComponentManagerImpl::CreateInstanceByContractID(char
const*, nsISupports*, nsID const&, void**)
(this=0x3fb3b0,aContractID=0x64102210
"@mozilla.org/chrome/chrome-registry;1", aDelegate=0x0,aIID=@0x64128768,
aResult=0x22f5d0) at
c:/mozilla/source/mozilla/xpcom/components/nsComponentManager.cp p:2012 #9
 0x67fe1b71 in nsComponentManagerImpl::GetServiceByContractID(char const*,
ns ID const&, void**) (this=0x3fb3b0, aContractID=0x64102210
"@mozilla.org/chrome/chrome-registry;1", aIID=@0x64128768,
result=0x22f684) at
c:/mozilla/source/mozilla/xpcom/components/nsComponentManager.cp p:2420
#10 0x680353c0 in nsGetServiceByContractID::operator()(nsID const&,
void**) const (this=0x22f720, aIID=@0x64128768, aInstancePtr=0x22f684) at
c:/mozilla/source/mozilla/xpcom/glue/nsComponentManagerUtils.cpp:12 1 #11
0x64126138 in
nsCOMPtr<nsIXULChromeRegistry>::assign_from_helper(nsCOMPtr_h elper
const&, nsID const&) (this=0x22f730, helper=@0x22f720,aIID=@0x64128768) at
 ../../dist/include/xpcom/nsCOMPtr.h:988 #12 0x64126275 in
nsCOMPtr<nsIXULChromeRegistry>::nsCOMPtr(nsCOMPtr_helper const &)
(this=0x22f730, helper=@0x22f720) at
../../dist/include/xpcom/nsCOMPtr.h:560 #13 0x6410a9fa in
nsProfile::DefineLocaleDefaultsDir() (this=0x11e9850) at
c:/mozilla/source/mozilla/profile/src/nsProfile.cpp:2082 #14 0x64107641 in
nsProfile::SetCurrentProfile(wchar_t const*) (this=0x11e9850,
aCurrentProfile=0x120b0e0) at
c:/mozilla/source/mozilla/profile/src/nsProfile.cpp:1260 #15 0x64103637 in
nsProfile::LoadDefaultProfileDir(nsCString&, int) (this=0x11e9850,
profileURLStr=@0x22fc60, canInteract=1) at
c:/mozilla/source/mozilla/profile/src/nsProfile.cpp:548 #16 0x641022e5 in
nsProfile::StartupWithArgs(nsICmdLineService*, int) (this=0x11e9850,
cmdLineArgs=0x1218710, canInteract=1) at
c:/mozilla/source/mozilla/profile/src/nsProfile.cpp:356 #17 0x61591410 in
nsAppShellService::DoProfileStartup(nsICmdLineService*, int) (
this=0x1218b20, aCmdLineService=0x1218710, canInteract=1) at
c:/mozilla/source/mozilla/xpfe/appshell/src/nsAppShellService.cpp:273 #18
0x00403a8d in InitializeProfileService(nsICmdLineService*)
(cmdLineArgs=0x1218710) at
c:/mozilla/source/mozilla/xpfe/bootstrap/nsAppRunner.cpp:905 #19
0x00404f5e in main1(int, char**, nsISupports*) (argc=1, argv=0x3f26e0,
nativeApp=0x1186b58) at
c:/mozilla/source/mozilla/xpfe/bootstrap/nsAppRunner.cpp:1183 #20
0x00405fc7 in main (argc=1, argv=0x3f26e0) at
c:/mozilla/source/mozilla/xpfe/bootstrap/nsAppRunner.cpp:1650

Comment 288

[timeless]

please attach your installed-chrome.txt file, it probably has cygdrive in it,
imo it shouldn't. mozilla.exe shouldn't require any traces of cygwin.

Comment 289

[David G King]

Attachment: installed-chrome.txt

installed-chrome.txt as per request from timeless. It doesn't look like it's
the problem.

Comment 290

[timeless]

oh, eek, sorry. what are %TEMP% %TMP% %TEMPDIR% ?

Comment 291

[David G King]

TEMP=C:\WIND\TEMP
TMP=C:\WIND\TEMP
I don't have TEMPDIR set.

I've always wondered if TMP should be set to a cygdrive type directory, but have
never got around to it. I can't change TEMP as other programs under WIN32 use it.

Comment 292

[David G King]

After some more digging, and learning gdb the hard way, it looks like the
problem has something to do with : /xpcom/io/nsDirectoryServiceDefs.h, line 67
-- #define NS_OS_TEMP_DIR "TmpD"

This is later used in : /netwerk/protocol/res/src/nsResProtocolHandler.cpp, line
135 -- rv = SetSpecialDir("tempdir", NS_OS_TEMP_DIR);
which seems to be the root cause of the problem. However, I have no idea as to
why this doesn't get the correct temp directory, or more correctly, insists on
adding C: to it.

Any ideas?

Comment 293

[cls]

Attachment: NSS mingw patch v1.7

This patch fixes the nssckbi.dll loading problem.  The problem was that we
weren't compiling NSS with -mms-bitfields and this caused certain structures to
be misaligned.

Comment 294

[timeless]

http://lists.act-europe.fr/pipermail/gvd-users/2002-January/000147.html
you were probably running mozilla in bash.
i'd like to blame cygwin bash for this :)

Comment 295

[David G King]

The TmpD thing was not the real problem. I got rid of all my environment temp
settings, and got rid of the error, but not the crash. However, I'll look into
that Bash possibility.

After some more work in gdb, I've got it down to
RDFContentSinkImpl::InitContainer in nsRDFContentSink.cpp. In particular : 
rv = (gRDFContainerUtils->*(info->mMakeFn))(mDataSource, aContainer, nsnull);
fails with the horrible error.
This is interesting, as a very similar version of this line is executed a few
lines earlier :
rv = (gRDFContainerUtils->*(info->mTestFn))(mDataSource, aContainer, &isContainer);

Some of this seems to track back to some def's in nscore.h which I'm currently
checking out.

Comment 296

[Wan-Teh Chang]

Attachment: NSS mingw patch v1.8

Comment 297

[cls]

Comment on attachment 120360 [details] [diff] [review]
NSS mingw patch v1.8

DLL_PREFIX isn't being set for gcc/win32.

Comment 298

[cls]

Attachment: NSS mingw patch v1.9

Comment 299

[Jonathan Wilson]

Questions:
1.are there any external events holding up this bug (such as more fixes to
windres still to come through the pipe?)
2.what is still to be fixed and checked in?
3.what still doesnt work?
and 4.is there anything about this bug and/or the remaining patches that will
mean it wont be done for 1.4?

Comment 300

[Christian Schmidt]

Re: Comment 112 about problems with linefeeds in glib.h and glibconfig.h
Actually (or at least the copy of moztools I just downloaded) the linefeeds are
not \n\n\n but \r\r\n i.e. some strange mix between Unix and DOS linefeeds.

Comment 301

[Wan-Teh Chang]

Attachment: NSS mingw patch v1.10 (incomplete, without library prefix and suffix changes) (checked in)

cls is still looking into what the prefix and
suffix for static and import libraries should be.
This patch excludes those changes.

I've convinced cls that the prefix and suffix for
DLLs should be the same as those of a MSVC build so
that DLLs' filenames have the "native look" and we
can potentially provide mingw import libraries for
MSVC-compiled DLLs where there is binary
compatibility between the two compilers (which
probably means C libraries only).

Comment 302

[cls]

Attachment: Change library naming scheme (checked in)

This patch changes the naming scheme for the core Mozilla libraries to be to
use the follow format:

static lib: libfoo.a
import lib: libfoo.dll.a
shared lib: foo.dll

Comment 303

[cls]

Attachment: NSS library naming scheme change (checked in)

Comment 304

[David G King]

Two issues with the NSS v1.10 patch (assuming it's still current which it seems
to be).

I can't get the patch to apply fully, I get the following :

patching file security/nss/cmd/dbtest/Makefile
assertion "hunk" failed: file "patch.c", line 341
      4 [sig] patch 3508 open_stackdumpfile: Dumping stack trace to patch.exe.st
ackdump

This is using cygwin's patch v2.5.8

The second issue is this. Why patch Makefile, when this file will be deleted
when I next do a build distclean and then recreated from Makefile.in when I do a
build alldep?

Comment 305

[Wan-Teh Chang]

Comment on attachment 121160 [details] [diff] [review]
NSS library naming scheme change (checked in)

r=wtc.

Comment 306

[Dan Mosedale (:dmosedale, :dmose)]

Comment on attachment 117819 [details] [diff] [review]
resource changes v1.1 (checked in)


r=[e-mail]

Comment 307

[Dan Mosedale (:dmosedale, :dmose)]

Comment on attachment 121156 [details] [diff] [review]
Change library naming scheme (checked in)


r=[e-mail]

Comment 308

[Jonathan Wilson]

ok, so what is still to be checked in, what extra tools (other than those listed
in the build instructions, do you e.g. need a special version of glib and
libidl) do you need to build this and what features dont yet work?

Also, is this likely to be "completed" for 1.4? (i.e. 1.4 building out of the
box from a tarball and a set of build instructions using MingW GCC)

Comment 309

[Dimitrie O. Paun]

cls, I'm not sure those ugly resource changes needed to get checked in. 
windres is fixed right now to handle those, and a release is within reach 
(I would think 2-3 weeks). 
 
Also, my -J patch for windres is now in as well, and another one for -fo 
is pending, which means that we can remove all the ugly ifdefs around the 
resource compilers from the Makefiles, because now windres should be 
command line compatible with rc as far as we're concerned. 

Comment 310

[cls]

dpaun, 2-3 weeks is basically out of reach.  According to the roadmap, mozilla
1.4b is due to be released by the end of the week.  (It'll probably take at
least a full week to freeze but the point still stands.)  We're not going to
hold the Mozilla release for a binutils release for a *cosemtic* build fix.  Nor
are we going to start recommending/requiring the use of unreleased/cvs versions
of tools.  Slipping the landing of the final piece needed for mingw support at
this point seems like a waste of time all around so the ugly patch went in.

All of the necessary patches have been checked in.  The standard win32 build
page has been updated with the mingw build information.

Open new bugs on any future problems or leftover issues, like the rasdlg &
windres issues.

Comment 311

[David G King]

I agree with cls, a working WIN32 gcc build capability needed to get in for 1.4b
to give the most time for testing before 1.4final is released.

And anyway, I'm finding this particular bug to be really hard to navigate as it
has become rather large.

CLS: I checked http://www.mozilla.org/build/win32.html as I wanted to see what
it looked like on mozilla.org, but it seems to still be the old version. I
didn't think this was worthy of a new bug....but I'm willing to file one if you
want.

Comment 312

[Zook Valem]

Since the bug is resolved as fixed.  It would be appreciate and be helpful that
if any future bug that is filed to have some kind of reference to this one, so
we can keep track of the bugs.

Thanks,
 ZookQValem

Comment 313

[Dimitrie O. Paun]

We should remove 202868 as a blocked bug, it's bound to 203303 now which is more appropriate.