make mozilla build on win32 using GCC

RESOLVED FIXED in mozilla1.4beta

Status

enhancement
RESOLVED FIXED
17 years ago
13 years ago

People

(Reporter: jonwil, Assigned: cls)

Tracking

(Blocks 1 bug)

Trunk
mozilla1.4beta
x86
Windows XP
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(27 attachments, 65 obsolete attachments)

10.65 KB, patch
mcs
: review+
Details | Diff | Splinter Review
7.34 KB, patch
bryner
: review+
Details | Diff | Splinter Review
21.25 KB, patch
bryner
: review+
Details | Diff | Splinter Review
2.05 KB, patch
cls
: review+
sspitzer
: superreview+
Details | Diff | Splinter Review
20.66 KB, patch
bbaetz
: review+
Details | Diff | Splinter Review
16.09 KB, patch
dougt
: review+
dbaron
: superreview+
Details | Diff | Splinter Review
3.22 KB, patch
mozilla
: review+
Details | Diff | Splinter Review
13.50 KB, patch
dbradley
: review+
Details | Diff | Splinter Review
1.82 KB, patch
beard
: review+
blizzard
: superreview+
Details | Diff | Splinter Review
4.73 KB, patch
peterlubczynski-bugs
: review+
dbaron
: superreview+
Details | Diff | Splinter Review
1.92 KB, patch
brendan
: review+
Details | Diff | Splinter Review
1.83 KB, patch
ssu0262
: review+
dveditz
: superreview+
Details | Diff | Splinter Review
2.33 KB, patch
dougt
: review+
Details | Diff | Splinter Review
491 bytes, patch
pavlov
: review+
Details | Diff | Splinter Review
1.22 KB, patch
bzbarsky
: review+
sspitzer
: superreview+
Details | Diff | Splinter Review
3.00 KB, patch
pavlov
: review+
blizzard
: superreview+
Details | Diff | Splinter Review
8.63 KB, patch
kmcclusk
: review+
blizzard
: superreview+
Details | Diff | Splinter Review
901 bytes, patch
asasaki
: review+
Details | Diff | Splinter Review
3.81 KB, patch
bbaetz
: review+
darin.moz
: superreview+
Details | Diff | Splinter Review
7.58 KB, patch
dmose
: review+
Details | Diff | Splinter Review
681 bytes, patch
darin.moz
: review+
Details | Diff | Splinter Review
6.33 KB, patch
cls
: review+
dbaron
: superreview+
Details | Diff | Splinter Review
27.25 KB, text/html
Details
5.83 KB, text/plain
Details
27.59 KB, patch
cls
: review+
Details | Diff | Splinter Review
8.15 KB, patch
dmose
: review+
Details | Diff | Splinter Review
818 bytes, patch
wtc
: review+
Details | Diff | Splinter Review
Reporter

Description

17 years ago
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.
Reporter

Updated

17 years ago
Severity: normal → enhancement
Keywords: helpwanted
Reporter

Comment 1

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

confirming
Blocks: 65928
Status: UNCONFIRMED → NEW
Ever confirmed: true
Reporter

Updated

17 years ago
Status: NEW → ASSIGNED
Reporter

Comment 4

17 years ago
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)
Reporter

Comment 5

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


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

Comment 7

17 years ago
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 :(
Reporter

Comment 8

17 years ago
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)
Reporter

Updated

17 years ago
OS: Windows ME → Windows XP
Reporter

Comment 9

17 years ago
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

17 years ago
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.
Reporter

Comment 11

17 years ago
Posted patch patch v2 (obsolete) β€” β€” Splinter Review
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

17 years ago
What's the error output at the w95cv.c break?
Reporter

Comment 13

17 years ago
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...
Assignee

Updated

17 years ago
Attachment #78880 - Attachment is obsolete: true
Assignee

Updated

17 years ago
Attachment #79040 - Flags: needs-work+
Assignee

Comment 14

17 years ago
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()?
Reporter

Comment 15

17 years ago
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.
Assignee

Comment 16

17 years ago
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.
Reporter

Comment 17

17 years ago
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)
Reporter

Comment 18

17 years ago
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
Reporter

Comment 19

17 years ago
Posted patch patch v3 (obsolete) β€” β€” Splinter Review
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

17 years ago
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.
Reporter

Comment 21

17 years ago
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.

Reporter

Comment 22

17 years ago
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.


Reporter

Comment 23

17 years ago
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.
Reporter

Comment 24

17 years ago
Posted patch patch v4 (obsolete) β€” β€” Splinter Review
Here is the state of play with patch v4
building with --enable-win32-target=WIN95 and --with-mozilla gets up to the
link stage but then bombs out with errors about cant find API functions, I am
working on that one. Have tried some linker stuff that helps a little. Its
finding the libraries but not the functions within, dont know why. Also I cant
seem to convince it to properly link to the mingw32 libraries. (its not finding
the mingw library files if I add -lmsvcrt etc)
building with --enable-win32-target=WINNT builds up to ntio.c but then
complains that the defintions of some of the functions in that file are
different from the primpl.h file. Anyone here want to tell me why and what to
do to fix it?
other than that, so far so good.

Let me explain some of the things I have done in the patch:
All changes to the build process are done with NS_USE_GCC as recommended by
seawood.
The changes to now.c are needed since for some reason cygwin with mingw doesnt
like something within the code (not sure what)
The changes to _winnt.h are needed to get something to compile properly.
ntintrval.c changes are because gcc doesnt like nameless unions.
the changes to ntio.c and w95io.c are to do with the nameless unions thing and
also a problem with cygwin/mingw32 not having a mbstring.h file.
win32_errors.c was changed because the windows socket errors arent pulled by
cygwin header files unless you include winsock.h
the changes to w95dllmain.c and w95cv.c are because of a problem with cygwin
and mingw32.
For some odd reason, cygwin with mingw32 #defines WINNT as an intrinsinc (just
like it #defines __MINGW32__).
Currently, what I have is a kludge. Any suggestions of how to fix this without
changing cygwin/mingw (which isnt an option since it appears as though this
stuff is hardcoded somewhere) or requiring heaps of effort would be
appreciated...
Best way IMHO is to add the check to some global header file that gets pulled
in before the code that pulls _winnt.h or _win95.h
Can you use ifdef NS_USE_GCC ... else ... endif instead of ifndef NS_USE_GCC ...
? It's more readable that way (at least imho).

Also, please don't use tabs (you used them in at least one place).
oh yeah, one more thing: you have rather many lines like this:
+     ifdef NS_USE_GCC
+
$(CCC) -o $@ -c $(CCCFLAGS) $<
+     else
 	$(CCC) -Fo$@ -c $(CCCFLAGS) $<
+     endif

What about doing something like this:
ifdef NS_USE_GCC
  OUTOPT=-o\ 
else
  OUTOPT)-Fo
endif

and later always use $(CCC) $(OUTOPT)$@ -c $(CCCFLAGS) $<
Reporter

Comment 27

17 years ago
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
Reporter

Comment 28

17 years ago
Posted patch patch v5 (obsolete) β€” β€” Splinter Review
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

Updated

17 years ago
Attachment #79040 - Attachment is obsolete: true

Updated

17 years ago
Attachment #79052 - Attachment is obsolete: true

Updated

17 years ago
Attachment #79130 - Attachment is obsolete: true

Updated

17 years ago
Attachment #79133 - Flags: needs-work+
Assignee

Comment 29

17 years ago
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?
Reporter

Comment 30

17 years ago
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.
Assignee

Comment 31

17 years ago
> 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.


Posted patch mingw gcc patch v1 (obsolete) β€” β€” Splinter Review
This patch also NSPR to build using the mingw 1.0.1 snapshot.	
env CC=gcc CXX=g++ ./configure --enable-win32-target=WIN95 

The patch incorporates most of the code changes from the previous patches, uses
OUTOPTION, and tweaks some rules to build DLLs using dllwrap & dlltool.  I also
switch from using AC_PATH_PROGS to AC_CHECK_PROGS to avoid dealing with cygwin
path issues when using mingw's make.

Some of the pr/tests work but most fail. :-/  I suspect that's not normal.
 # Bug 122433 workaround: disable global optimization (-Og-) on ntio.c.
 ifdef BUILD_OPT
 ifeq ($(OS_TARGET), WINNT)
+ifdef NS_USE_GCC
+CFLAGS := $(subst -O%,,$(CFLAGS))

Hm... I wonder if that bug also occurs with GCC compilers... maybe it's a MSVC
specific problem and works with gcc even with optimization?
Reporter

Comment 34

17 years ago
Comment on attachment 79133 [details] [diff] [review]
patch v5

Marking obsolete since seawoods idea of using mingw makes more sense
Attachment #79133 - Attachment is obsolete: true
Reporter

Comment 35

17 years ago
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.
Attachment #79142 - Flags: needs-work+
Reporter

Comment 36

17 years ago
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)
Reporter

Comment 37

17 years ago
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

17 years ago
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.
Reporter

Comment 39

17 years ago
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

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

Comment 42

17 years ago
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)
Posted patch mingw gcc patch v2 (obsolete) β€” β€” Splinter Review
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.
Attachment #79142 - Attachment is obsolete: true
Reporter

Comment 44

17 years ago
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?
Reporter

Comment 45

17 years ago
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.
Posted patch some changes dbaron was working on (obsolete) β€” β€” Splinter Review
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.
Reporter

Comment 47

17 years ago
Posted patch new patch for main moz tree (obsolete) β€” β€” Splinter Review
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
Attachment #79620 - Attachment is obsolete: true
+
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??
Reporter

Comment 49

17 years ago
Posted patch new patch (obsolete) β€” β€” Splinter Review
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?
Attachment #80265 - Attachment is obsolete: true

Comment 50

17 years ago
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.
Reporter

Comment 51

17 years ago
Posted patch current patch (obsolete) β€” β€” Splinter Review
current patch I have been working on.
Stuck until I can get a libidl and a glib that work on mozilla
Attachment #80572 - Attachment is obsolete: true
Reporter

Comment 52

17 years ago
updated this to the latest copies of config/rules.mk and config/autoconf.mk.in
Attachment #81130 - Attachment is obsolete: true
Reporter

Comment 53

17 years ago
visual C builds will still compile even if the username has whitespace, GCC
builds wont. Making 137059 as a dependancy.
Depends on: 137059
Reporter

Comment 54

17 years ago
Posted patch patch including the fix for 137059 (obsolete) β€” β€” Splinter Review
this contains the fix for bug 137059
marking dbarons changes obsolete since current patches include all those
changes
Attachment #79605 - Attachment is obsolete: true
Attachment #79988 - Attachment is obsolete: true

Comment 55

17 years ago
What is the status of patches?
Are all things completed?
Reporter

Comment 56

17 years ago
No, the patches arent anywhere near finished.
Posted patch NSPR mingw gcc v3 patch (obsolete) β€” β€” Splinter Review
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.
Assignee

Comment 58

17 years ago
Posted patch moz mingw v6 patch (obsolete) β€” β€” Splinter Review
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
Attachment #81134 - Attachment is obsolete: true
Attachment #81139 - Attachment is obsolete: true
Reporter

Comment 59

17 years ago
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.
Assignee

Comment 60

17 years ago
Well, we saw how well waiting for that mysterious "someone" worked with the
motif port and now the qt port.  Are you volunteering to be that "someone"?  And
"once it successfully builds and runs" also implies that "someone" is going to
take it that next step.  It's not going to evolve on its own.
So Chris, is this work or a hobby? If Netscape is paying to get this going then
surely they can afford to throw an old crummy box on tinderbox to run this.
Otherwise it was wasted time.
Assignee

Comment 62

17 years ago
Afaik, Netscape has no interest in this work.  Certainly no investment as it was
done on my own time using one of my spare machines  (slag's back to doing the
beos tinderbox).  As I wrote to several members of mozilla.org earlier, it was
mainly for hack value.  I've been interested to see if this could be done since
1999.  Now that it's almost done, the question becomes what to do with it? IMO,
no maintainer == bitrotten code.  It's just a matter of time. 

I think that the assertion of not being netscape backed == waste of time is
invalid.  If it's not backed by mozilla.org, then it's a waste of time as it
shouldn't go into the tree.  But that gets us off into a completely off-topic
discussion regarding who controls or should control the tree.
Who controls the tree?  mozilla.org, duh.  We're happy to have well-owned build
fu like this, but that takes us back to the real quesiton: not who "controls"
the tree, but who will own these files and keep things from rotting.

If we add a ports tinderbox and it turns red, will anyone in the community fix
the problems (with help from those whose changes were problematic, if needed)? 
Who is that "anyone"?

/be
Sorry, my comment came out harsher than I meant. I meant that *IF* netscape had
paid for this (which turns out to be false) then it would be foolish of them not
to go the next step and donate a tbox machine for it to keep it from bitrotting.

But since this wasn't a Netscape project we'll have to look for someone else to
adopt it.
Reporter

Comment 65

17 years ago
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?
Assignee

Comment 66

17 years ago
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.

Reporter

Comment 67

17 years ago
I doubt you will be able to get MFC and ATL working on mingw as they are
microsoft only libs.
> Ignoring the differences in the perceived reasons for doing 
> this, if the code isn't maintained and bitrots, it doesn't 
> help anyone contribute.  

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

Comment 69

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

Comment 70

17 years ago
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.
Reporter

Comment 71

17 years ago
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.
Assignee

Comment 72

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

The whole thing is a moot point if we have people just saying what needs to be
done rather than actually doing it.  Contributors wanted. Maintainers needed.


Reporter

Comment 73

17 years ago
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.
Reporter

Comment 74

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

Comment 75

17 years ago
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

17 years ago
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

17 years ago
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

17 years ago
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. 
Assignee

Comment 79

17 years ago
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

17 years ago
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?

Assignee

Comment 81

17 years ago
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

17 years ago
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>
Posted patch NSPR mingw gcc3 v1.0 (obsolete) β€” β€” Splinter Review
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.
Attachment #89945 - Attachment is obsolete: true

Comment 84

17 years ago
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? 
Assignee

Comment 85

17 years ago
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.

Assignee

Comment 86

17 years ago
Posted patch nobrainer build changes v1.0 (obsolete) β€” β€” Splinter Review
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.
Attachment #92539 - Attachment is obsolete: true
Comment on attachment 110570 [details] [diff] [review]
nobrainer build changes v1.0

r=dmose
Attachment #110570 - Flags: review+

Comment 88

17 years ago
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 :)
Assignee

Comment 89

17 years ago
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

17 years ago
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 :)
Assignee

Comment 91

17 years ago
Posted patch straight code changes v1.0 (obsolete) β€” β€” Splinter Review
Attachment #110570 - Attachment is obsolete: true
Assignee

Comment 92

17 years ago
Posted patch rest of gcc3 changes v1.0 (obsolete) β€” β€” Splinter Review
I'm too tired to break this up any further so here's the rest of the changes.
as for declspec(thread):
I think this can be used for gcc/g++:
http://gcc.gnu.org/onlinedocs/gcc/Thread-Local.html
but, I have no idea since when gcc supports that.

>The nobrainer one looks very good, it should go in IMO.

it is in already :)

Comment 95

17 years ago
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

17 years ago
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

17 years ago
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

17 years ago
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

17 years ago
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.
Assignee

Comment 100

17 years ago
Posted patch NSPR mingw gcc v1.1 (obsolete) β€” β€” Splinter Review
* 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
Attachment #110563 - Attachment is obsolete: true

Comment 101

17 years ago
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?
Assignee

Comment 102

17 years ago
Posted file test logfile (obsolete) β€”
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.
Assignee

Comment 103

17 years ago
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

17 years ago
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

17 years ago
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

17 years ago
Does checkin in the early morning yesterday break calendar building ?

Cf bug 187663 I filled this morning.

Comment 107

17 years ago
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?
Assignee

Comment 108

17 years ago
Posted patch NSPR mingw gcc3 v1.2 (obsolete) β€” β€” Splinter Review
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.
Attachment #110643 - Attachment is obsolete: true
Attachment #110645 - Attachment is obsolete: true
Assignee

Comment 109

17 years ago
Posted patch moz mingw gcc3 v1.1 (obsolete) β€” β€” Splinter Review
* 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
Attachment #110578 - Attachment is obsolete: true
Attachment #110579 - Attachment is obsolete: true
Reporter

Comment 110

17 years ago
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.
Posted patch NSPR ming gcc3 v1.3 (obsolete) β€” β€” Splinter Review
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?
Attachment #110670 - Attachment is obsolete: true
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.
Posted patch NSPR mingw gcc3 patch v1.4 (obsolete) β€” β€” Splinter Review
More code landed on the NSPR branch that used i64 syntax on XP_WIN.  Added
__GNUC__ bracketed changes to cope with this.
Attachment #111362 - Attachment is obsolete: true
Posted patch moz mingw gcc3 patch, v1.2 (obsolete) β€” β€” Splinter Review
* 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

17 years ago
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?
Assignee

Comment 116

17 years ago
dmose, I havent looked at the patch but something is broken if you are using
HOST_CFLAGS. HOST_CFLAGS is only used when cross-compiling or building
nsinstall.  nsinstall comes with wintools.zip so it is not built by default for
win32 regardless of compiler.  The msvc switches are needed to a) force msvc to
treat the file as C instead of attempting to autodetect it & b) avoid the
annoying msvc copyright on every execution.  The autodetection is avoided so
that the autoconf c++ tests actually work.  The autoconf tests use .C as the
name of the c++ file which on a case-insensitive file system causes the c++
files to be treated as C files.

wtc,
1) The mingw tools are native win32 executables.  They have no knowledge of
cygwin semantics so they must be wrapped as well.
Yes, the msvc build hardcodes the rc.exe as it always has.
2) Yes, the distinction is intentional.  __GNUC__ ifdefs refer to compiler
specific changes such as MSVC using i64 to denote a 64bit int and gcc using LL.
 __MINGW32__ ifdefs refer to changes that are specific to the mingw
implementation of the win32 api.
My bad.  mkdepend also uses the HOST_CFLAGS rules due to bug 179895.  I missed
this problem because I had makedepend installed from Cygwin's XFree86 package. 
Posted patch moz mingw gcc 3 patch, v1.3 (obsolete) β€” β€” Splinter Review
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.
Attachment #110672 - Attachment is obsolete: true
Attachment #111605 - Attachment is obsolete: true
Posted patch moz mingw gcc3 patch, v1.4 (obsolete) β€” β€” Splinter Review
* 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.
Attachment #111903 - Attachment is obsolete: true
Comment on attachment 111925 [details] [diff] [review]
moz mingw gcc3 patch, v1.4

Whoops, attached the wrong file.
Attachment #111925 - Attachment is obsolete: true

Comment 121

17 years ago
Posted patch NSPR mingw gcc3 patch v1.5 (obsolete) β€” β€” Splinter Review
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.
Attachment #111604 - Attachment is obsolete: true
Posted patch moz mingw gcc3 patch v1.5 (obsolete) β€” β€” Splinter Review
Attach the correct file for the 1.4 changes.  Also, instead of trying to do the
inline assembly stuff for XPCOM_DEBUG_BREAK and XPCOM_BREAK_ON_LOAD on all x86
platforms, just do it on x86 platforms running gcc, since other compilers are
likely to use a different syntax.
+ifndef GNU_CC
 ifndef NO_MFC

couldn't you, instead, define NO_MFC in win32/gcc builds?
Posted patch moz mingw gcc3 patch v1.6 (obsolete) β€” β€” Splinter Review
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__
Attachment #112039 - Attachment is obsolete: true

Comment 125

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

I've checked in this NSPR patch.

Comment 126

17 years ago
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
Assignee

Comment 127

17 years ago
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.

Assignee

Comment 128

17 years ago
Posted patch NSS mingw patch v1.1 (obsolete) β€” β€” Splinter Review
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

17 years ago
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

17 years ago
how much of cygwin/mingw32 etc do you actually need ?

I'm building daily under Linux (both Moz and Px)

I would like to try this Win98SE
Comment on attachment 111962 [details] [diff] [review]
NSPR mingw gcc3 patch v1.5

Marking obsolete since this has been checked in.
Attachment #111962 - Attachment is obsolete: true
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

17 years ago
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

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

Comment 135

17 years ago
not quite bugspam:

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

Comment 136

17 years ago
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 ?
Assignee

Comment 137

17 years ago
Posted file NSS test results.html (obsolete) β€”
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?
Assignee

Comment 138

17 years ago
Posted patch NSS mingw patch v1.2 (obsolete) β€” β€” Splinter Review
Changes to get NSS tests running.
Attachment #112395 - Attachment is obsolete: true
Assignee

Comment 139

17 years ago
Posted patch NSS mingw patch v1.3 (obsolete) β€” β€” Splinter Review
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.
Attachment #113250 - Attachment is obsolete: true
Attachment #113251 - Attachment is obsolete: true
Assignee

Comment 140

17 years ago
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.

Depends on: 176501
Alias: mingw
Posted patch moz ming gcc3 patch v1.7 (obsolete) β€” β€” Splinter Review
* 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"
Attachment #112138 - Attachment is obsolete: true
Assignee

Comment 142

17 years ago
Alias: mingw → java
Alias: java → mingw
Assignee

Comment 143

17 years ago
Posted patch moz mingw gcc3 v1.8 (obsolete) β€” β€” Splinter Review
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
Attachment #114293 - Attachment is obsolete: true
Assignee

Comment 144

17 years ago
Posted patch NSS mingw patch v1.4 (obsolete) β€” β€” Splinter Review
Just removing the diff cruft added by $Id$
Attachment #113680 - Attachment is obsolete: true
Assignee

Comment 145

17 years ago
Posted patch moz mingw gcc3 patch v1.9 (obsolete) β€” β€” Splinter Review
* 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.
Attachment #115478 - Attachment is obsolete: true
Assignee

Comment 146

17 years ago
Let's get this party started...
Assignee: jonwil → cls
Status: ASSIGNED → NEW
Target Milestone: --- → mozilla1.4alpha
Assignee

Comment 147

17 years ago
Attachment #116042 - Attachment is obsolete: true
Assignee

Comment 148

17 years ago
Assignee

Updated

17 years ago
Attachment #116364 - Flags: review?(bryner)
Assignee

Updated

17 years ago
Attachment #116366 - Flags: review?(bryner)
Assignee

Comment 149

17 years ago
Posted patch xptcall changes (obsolete) β€” β€” Splinter Review
Assignee

Updated

17 years ago
Attachment #116370 - Flags: review?(dbradley)
Assignee

Comment 150

17 years ago
Posted patch rdf changes (obsolete) β€” β€” Splinter Review
Assignee

Comment 151

17 years ago
Assignee

Updated

17 years ago
Attachment #116377 - Flags: superreview?(sspitzer)
Attachment #116377 - Flags: review+
Assignee

Updated

17 years ago
Attachment #116374 - Flags: review?(rjc)
Reporter

Comment 152

17 years ago
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?
Assignee

Comment 153

17 years ago
Posted patch cleanup of XP code (obsolete) β€” β€” Splinter Review
Assignee

Comment 154

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

Updated

17 years ago
Attachment #116379 - Flags: superreview?(dbaron)
Attachment #116379 - Flags: review?(dougt)
Comment on attachment 116377 [details] [diff] [review]
msg protocol changes (checked in)

if that works, sr=sspitzer
Attachment #116377 - Flags: superreview?(sspitzer) → superreview+
Assignee

Comment 156

17 years ago
Posted patch mingw specific code changes (obsolete) β€” β€” Splinter Review
Assignee

Comment 157

17 years ago
Posted patch resource changes (obsolete) β€” β€” Splinter Review
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.
Assignee

Updated

17 years ago
Attachment #116381 - Flags: superreview?(dbaron)
Attachment #116381 - Flags: review?(brendan)
Comment on attachment 116379 [details] [diff] [review]
cleanup of XP code

>Index: content/svg/content/src/nsSVGValue.h
>@@ -44,7 +44,7 @@
> #include "nsISVGValueObserver.h"
> 
> // XXX this should be somewhere else
>-#if defined(XP_PC) && !defined(XP_OS2)
>+#ifdef _MSC_VER
> #define STDCALL __stdcall
> #else
> #define STDCALL

This should really be using something from nscore.h, but it doesn't look like
there's anything that works for pointer-to-member (like NS_CALLBACK_).	Could
we make something?  Shouldn't you be using __stdcall, or doesn't gcc support
it?  The nscore.h stuff uses the NS_WIN32 macro to test for Windows.

>Index: db/mork/src/morkSearchRowCursor.h
>@@ -116,8 +116,10 @@
>   virtual mork_bool CanHaveDupRowMembers(morkEnv* ev);
>   virtual mork_count GetMemberCount(morkEnv* ev);
> 
>+#ifdef NEEDED
>   virtual orkinTableRowCursor* AcquireUniqueRowCursorHandle(morkEnv* ev);
>-  
>+#endif
>+
>   // virtual mdb_pos NextRowOid(morkEnv* ev, mdbOid* outOid);
>   virtual morkRow* NextRow(morkEnv* ev, mdbOid* outOid, mdb_pos* outPos);
> 

Could you change this and the corresponding |#ifdef NEEDED| to |#if 0|?  (See
our C++ portability guidelines for why. :-)


Other than that, sr=dbaron.
Comment on attachment 114294 [details] [diff] [review]
LDAP mingw patch v1.0 (checked in)

sr=dmose for the client ldap branch
Attachment #114294 - Flags: superreview+
Assignee

Comment 160

17 years ago
Assignee

Updated

17 years ago
Attachment #114294 - Flags: review?(mcs)

Comment 161

17 years ago
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

17 years ago
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.
Assignee

Comment 163

17 years ago
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.
Attachment #116379 - Attachment is obsolete: true
Attachment #116379 - Flags: superreview?(dbaron)
Attachment #116379 - Flags: review?(dougt)

Comment 164

17 years ago
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"
Assignee

Comment 165

17 years ago
> 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

17 years ago
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.
Assignee

Comment 167

17 years ago
Assignee

Comment 168

17 years ago
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.
Attachment #116374 - Attachment is obsolete: true
Assignee

Updated

17 years ago
Attachment #116374 - Flags: review?(rjc)

Comment 169

17 years ago
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?
Assignee

Updated

17 years ago
Attachment #116453 - Flags: review?(dougt)
Assignee

Updated

17 years ago
Attachment #116459 - Flags: superreview?(alecf)
Attachment #116459 - Flags: review?(rjc)
Assignee

Comment 170

17 years ago
gcc warns & msvc errors if |static const| is added before the gContainerInfo
definition:  "invalid conversion from 'const RDFContentSinkImpl::ContainerInfo*'
to 'RDFContentSinkImpl::ContainerInfo*' on the line with the for loop.  Just
|static| works though.
(What if you change the for loop to "for (const ContainerInfo* ..."?)

Comment 172

17 years ago
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.
Assignee

Comment 173

17 years ago
Addind const in both places works.

Comment 174

17 years ago
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.
Attachment #116459 - Flags: superreview?(alecf) → superreview+
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,
Assignee

Comment 176

16 years ago
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.

Updated

16 years ago
Attachment #116453 - Flags: review?(dougt) → review+
Assignee

Updated

16 years ago
Attachment #116453 - Attachment description: xp code changes v1.2 → xp code changes v1.2 (checked in)
Assignee

Updated

16 years ago
Attachment #116377 - Attachment description: msg protocol changes → msg protocol changes (checked in)
Assignee

Comment 177

16 years ago
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.
Attachment #116370 - Attachment is obsolete: true
Assignee

Updated

16 years ago
Attachment #116370 - Flags: review?(dbradley)
Assignee

Updated

16 years ago
Attachment #116533 - Flags: review?(dbradley)
Comment on attachment 114294 [details] [diff] [review]
LDAP mingw patch v1.0 (checked in)

The LDAP changes look OK.
Attachment #114294 - Flags: review?(mcs) → review+
Assignee

Comment 179

16 years ago
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.
Attachment #114294 - Attachment description: LDAP mingw patch v1.0 → LDAP mingw patch v1.0 (checked in)
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
Attachment #116381 - Flags: review?(brendan) → review+
Attachment #116366 - Flags: review?(bryner) → review+
Attachment #116364 - Flags: review?(bryner) → review+
Assignee

Comment 181

16 years ago
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 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
Attachment #116389 - Flags: review+
Assignee

Updated

16 years ago
Attachment #116364 - Attachment description: central makefile changes → central makefile changes (checked in)
Assignee

Updated

16 years ago
Attachment #116366 - Attachment description: other makefile changes → other makefile changes (checked in)
Assignee

Updated

16 years ago
Attachment #116389 - Attachment description: configure.in changes → configure.in changes (checked in)

Comment 183

16 years ago
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 :-/
Assignee

Comment 184

16 years ago
Posted patch gfx-widget-viewer changes (obsolete) β€” β€” Splinter Review
Attachment #116381 - Attachment is obsolete: true
Assignee

Comment 185

16 years ago
Posted patch imglib changes (obsolete) β€” β€” Splinter Review
Assignee

Comment 186

16 years ago
Assignee

Comment 187

16 years ago
Posted patch js changes (obsolete) β€” β€” Splinter Review
Assignee

Comment 188

16 years ago
Posted patch layout - mailnews changes (obsolete) β€” β€” Splinter Review
Assignee

Comment 189

16 years ago
Posted patch nsWindowsHooksUtil change (obsolete) β€” β€” Splinter Review
Assignee

Comment 190

16 years ago
Posted patch necko changes (obsolete) β€” β€” Splinter Review
Assignee

Comment 191

16 years ago
Posted patch plugin changes (obsolete) β€” β€” Splinter Review
Assignee

Comment 192

16 years ago
Posted patch remaining xpcom changes (obsolete) β€” β€” Splinter Review
Assignee

Comment 193

16 years ago
Posted patch xpinstall changes (obsolete) β€” β€” Splinter Review
Assignee

Updated

16 years ago
Attachment #116381 - Flags: superreview?(dbaron)
Assignee

Comment 194

16 years ago
Comment on attachment 116679 [details] [diff] [review]
js changes

Transferring brendan's r= for the js changes.
Attachment #116679 - Flags: superreview?(blizzard)
Attachment #116679 - Flags: review+
Assignee

Updated

16 years ago
Attachment #116685 - Flags: review?(dougt)
Assignee

Updated

16 years ago
Attachment #116686 - Flags: superreview?(dveditz)
Attachment #116686 - Flags: review?(ssu)
Assignee

Updated

16 years ago
Attachment #116677 - Flags: superreview?(tor)
Attachment #116677 - Flags: review?(pavlov)
Assignee

Updated

16 years ago
Attachment #116684 - Flags: superreview?(dbaron)
Attachment #116684 - Flags: review?(peterl)
Assignee

Updated

16 years ago
Attachment #116682 - Flags: superreview?(scc)
Attachment #116682 - Flags: review?(jaggernaut)
Assignee

Updated

16 years ago
Attachment #116680 - Flags: superreview?(sspitzer)
Attachment #116680 - Flags: review?(bzbarsky)
Assignee

Updated

16 years ago
Attachment #116676 - Flags: superreview?(rbs)
Attachment #116676 - Flags: review?(rods)
Assignee

Updated

16 years ago
Attachment #116683 - Flags: superreview?(darin)
Attachment #116683 - Flags: review?(bbaetz)
Assignee

Updated

16 years ago
Attachment #116678 - Flags: superreview?(blizzard)
Attachment #116678 - Flags: review?(joe.chou)
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?)
Attachment #116684 - Flags: superreview?(dbaron) → superreview+
Attachment #116679 - Flags: superreview?(blizzard) → superreview+
Attachment #116678 - Flags: superreview?(blizzard) → superreview+

Comment 196

16 years ago
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

16 years ago
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

16 years ago
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

16 years ago
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

16 years ago
Should this:  >+#ifdef __MINGW32__ >+#include <windows.h> >+#else > #include "afxres.h" >+#endif  just be:  #include <winresrc.h>  ? 
Comment on attachment 116679 [details] [diff] [review]
js changes

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

/be
Attachment #116679 - Flags: review+ → review?(brendan)

Comment 202

16 years ago
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
isn't this:
#if defined(XP_WIN32) || defined(XP_OS2)
equivalent to:
#ifdef XP_PC
?
Assignee

Comment 204

16 years ago
> 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

16 years ago
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.
Attachment #116683 - Flags: superreview?(darin) → superreview-
Assignee

Comment 206

16 years ago
> 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.
> > 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

16 years ago
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.
Attachment #116677 - Flags: review?(pavlov) → review-
Comment on attachment 116685 [details] [diff] [review]
remaining xpcom changes

okay.
Attachment #116685 - Flags: review?(dougt) → review+
Assignee

Comment 210

16 years ago
Posted patch imglib changes v1.1 (obsolete) β€” β€” Splinter Review
Attachment #116677 - Attachment is obsolete: true
Assignee

Updated

16 years ago
Attachment #116731 - Flags: review?(pavlov)

Comment 211

16 years ago
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 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?
Assignee

Comment 213

16 years ago
> 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.
Assignee

Updated

16 years ago
Attachment #116677 - Flags: superreview?(tor)
Assignee

Comment 214

16 years ago
Posted patch js changes v1.1 (obsolete) β€” β€” Splinter Review
Attachment #116679 - Attachment is obsolete: true

Comment 215

16 years ago
Comment on attachment 116684 [details] [diff] [review]
plugin changes

Do the default plugin's resources need these changes too?
Attachment #116684 - Flags: review?(peterl) → review+

Comment 216

16 years ago
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.
Attachment #116533 - Flags: review?(dbradley) → review+
Assignee

Comment 217

16 years ago
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.
Attachment #116533 - Attachment description: xptcall changes v1.3 → xptcall changes v1.3 (checked in)
Assignee

Comment 218

16 years ago
Posted patch remaining xpcom changes v1.1 (obsolete) β€” β€” Splinter Review
With dean's suggested changes.
Attachment #116685 - Attachment is obsolete: true
Assignee

Updated

16 years ago
Attachment #116679 - Flags: review?(brendan)
Assignee

Updated

16 years ago
Attachment #116763 - Flags: review?(brendan)
Assignee

Updated

16 years ago
Attachment #116790 - Flags: review?(dougt)
Assignee

Comment 219

16 years ago
*sigh* merged the wrong set of changes.
Attachment #116684 - Attachment is obsolete: true
Assignee

Updated

16 years ago
Attachment #116794 - Flags: superreview?(dbaron)
Attachment #116794 - Flags: review?(peterl)
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
Assignee

Comment 221

16 years ago
Attachment #116763 - Attachment is obsolete: true
Assignee

Updated

16 years ago
Attachment #116763 - Flags: review?(brendan)
Assignee

Updated

16 years ago
Attachment #116799 - Flags: review?(brendan)

Updated

16 years ago
Attachment #116794 - Flags: review?(peterl) → review+
Comment on attachment 116799 [details] [diff] [review]
js changes v1.2 (checked in)

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

/be
Attachment #116799 - Flags: review?(brendan) → review+
Attachment #116799 - Attachment description: js changes v1.2 → js changes v1.2 (checked in)
Attachment #116794 - Attachment description: plugin changes v2.0 → plugin changes v2.0 (checked in)
Assignee

Comment 223

16 years ago
Attachment #116686 - Attachment is obsolete: true
Attachment #116686 - Flags: superreview?(dveditz)
Attachment #116686 - Flags: review?(ssu)
Assignee

Updated

16 years ago
Attachment #116828 - Flags: review?(ssu)

Comment 224

16 years ago
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

16 years ago
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 <danny_r_smith_2001@yahoo.co.nz> wrote: >  --- David Fraser
<davidf@sjsoft.com> 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 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?
Attachment #116683 - Flags: review?(bbaetz) → review-

Comment 227

16 years ago
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?
Assignee

Comment 228

16 years ago
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?
Assignee

Updated

16 years ago
Attachment #116790 - Flags: review?(dougt)
Assignee

Updated

16 years ago
Attachment #116680 - Attachment is obsolete: true
Attachment #116680 - Flags: superreview?(sspitzer)
Attachment #116680 - Flags: review?(bzbarsky)
Comment on attachment 116459 [details] [diff] [review]
rdf changes v1.2 (checked in)

r=rjc
Attachment #116459 - Flags: review?(rjc) → review+

Updated

16 years ago
Attachment #116828 - Flags: review?(ssu) → review+
Assignee

Updated

16 years ago
Attachment #116828 - Flags: superreview?(dveditz)
Assignee

Comment 230

16 years ago
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.
Attachment #116790 - Attachment is obsolete: true
Assignee

Comment 231

16 years ago
Attachment #116731 - Attachment is obsolete: true
Assignee

Updated

16 years ago
Attachment #116925 - Flags: superreview?(tor)
Attachment #116925 - Flags: review?(pavlov)
Assignee

Comment 232

16 years ago
Assignee

Updated

16 years ago
Attachment #116924 - Flags: review?(dougt)
Assignee

Updated

16 years ago
Attachment #116927 - Flags: superreview?(sspitzer)
Attachment #116927 - Flags: review?(bzbarsky)
Assignee

Comment 233

16 years ago
Attachment #116676 - Attachment is obsolete: true
Assignee

Comment 234

16 years ago
Assignee

Updated

16 years ago
Attachment #116928 - Flags: superreview?(blizzard)
Attachment #116928 - Flags: review?(pavlov)
Assignee

Updated

16 years ago
Attachment #116676 - Flags: superreview?(rbs)
Attachment #116676 - Flags: review?(rods)
Assignee

Updated

16 years ago
Attachment #116929 - Flags: superreview?(blizzard)
Attachment #116929 - Flags: review?(rods)
Comment on attachment 116927 [details] [diff] [review]
addrbook changes (checked in)

r/sr=sspitzer on the addrbook changes.
Attachment #116927 - Flags: superreview?(sspitzer) → superreview+
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.
Attachment #116682 - Flags: review?(jaggernaut) → review+
Comment on attachment 116924 [details] [diff] [review]
remaining xpcom changes v1.2 (checked in)

you can kill WIN16 if you like.
Attachment #116924 - Flags: review?(dougt) → review+
Assignee

Updated

16 years ago
Attachment #116459 - Attachment description: rdf changes v1.2 → rdf changes v1.2 (checked in)
Assignee

Updated

16 years ago
Attachment #116924 - Attachment description: remaining xpcom changes v1.2 → remaining xpcom changes v1.2 (checked in)
Assignee

Comment 238

16 years ago
Posted patch necko changes v1.1 (obsolete) β€” β€” Splinter Review
Attachment #116683 - Attachment is obsolete: true
Assignee

Comment 240

16 years ago
Attachment #116948 - Attachment is obsolete: true
Attachment #116950 - Flags: superreview?(darin)
Attachment #116950 - Flags: review?(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?
Attachment #116950 - Flags: review?(bbaetz) → review+
Comment on attachment 116928 [details] [diff] [review]
gfx-viewer changes v1.2 (checked in)


rs=blizzard
Attachment #116928 - Flags: superreview?(blizzard) → superreview+
Comment on attachment 116929 [details] [diff] [review]
widget changes v1.2 (checked in)


rs=blizzard
Attachment #116929 - Flags: superreview?(blizzard) → superreview+
Assignee

Comment 244

16 years ago
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

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


sr=darin
Attachment #116950 - Flags: superreview?(darin) → superreview+

Comment 246

16 years ago
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?
Assignee

Comment 247

16 years ago
Per bug 180383, which added the build id to the product version, yes.
Status: NEW → ASSIGNED
Keywords: helpwanted
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.
Attachment #116927 - Flags: review?(bzbarsky) → review+
Comment on attachment 116927 [details] [diff] [review]
addrbook changes (checked in)

It's temporary until w32api includes LPADRBOOK & the various MAPI defines.
Attachment #116927 - Attachment description: addrbook changes → addrbook changes (checked in)
Attachment #116950 - Attachment description: necko changes v1.2 → necko changes v1.2 (checked in)

Updated

16 years ago
Attachment #116949 - Flags: review?(asasaki) → review+
Attachment #116949 - Attachment description: win32 versioning fix for official builds → win32 versioning fix for official builds (checked in)

Comment 250

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

please add this to the changes file...
Attachment #116925 - Flags: review?(pavlov) → review+

Comment 251

16 years ago
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?
Assignee

Comment 252

16 years ago
> 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.

Assignee

Updated

16 years ago
Attachment #116731 - Flags: review?(pavlov)
Comment on attachment 116828 [details] [diff] [review]
xpinstall changes v1.1 (checked in)


sr=dveditz
Attachment #116828 - Flags: superreview?(dveditz) → superreview+

Updated

16 years ago
Attachment #116925 - Flags: superreview?(tor) → superreview+
Assignee

Updated

16 years ago
Attachment #116929 - Flags: review?(rods) → review?(kmcclusk)
Assignee

Updated

16 years ago
Attachment #116925 - Attachment description: jpeg changes → jpeg changes (checked in)
Assignee

Updated

16 years ago
Attachment #116828 - Attachment description: xpinstall changes v1.1 → xpinstall changes v1.1 (checked in)
Assignee

Updated

16 years ago
Attachment #116678 - Flags: review?(joe.chou) → review?(beard)
Comment on attachment 116929 [details] [diff] [review]
widget changes v1.2 (checked in)


r=kmcclusk@netscape.com
Attachment #116929 - Flags: review?(kmcclusk) → review+
Assignee

Updated

16 years ago
Attachment #116929 - Attachment description: widget changes v1.2 → widget changes v1.2 (checked in)

Comment 255

16 years ago
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.   
Dimitrie: The not yet checked in patches are awaiting review. please be a bit
more patient :)

Assignee

Comment 257

16 years ago
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

16 years ago
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

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


r=pavlov
Attachment #116928 - Flags: review?(pavlov) → review+

Comment 260

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

r=beard
Attachment #116678 - Flags: review?(beard) → review+
Assignee

Updated

16 years ago
Attachment #116678 - Attachment description: sun-java changes → sun-java changes (checked in)
Assignee

Updated

16 years ago
Attachment #116928 - Attachment description: gfx-viewer changes v1.2 → gfx-viewer changes v1.2 (checked in)
Assignee

Comment 261

16 years ago
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
Attachment #116382 - Attachment is obsolete: true

Comment 262

16 years ago
Posted file gcc on WIN32 docs v1.0 (obsolete) β€”
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.
Assignee

Comment 263

16 years ago
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.
Attachment #117849 - Flags: review-

Comment 264

16 years ago
Posted file gcc on WIN32 docs 1.01 (obsolete) β€”
Make gcc instructions part of existing Win32 build instructions. I still need
to add Troubleshooting info, and tidy up the HTML.
Attachment #117849 - Attachment is obsolete: true

Comment 265

16 years ago
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

16 years ago
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

16 years ago
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. 
 
 
Assignee

Comment 268

16 years ago
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.

Target Milestone: mozilla1.4alpha → mozilla1.4beta