Derived from Meta bug 177789. This bug deals specifically with patches to make browser build on OS/2 using GCC 3.0.3. NSPR and LDAP builds are covered in bugs 188246 and 188247, respectively.

Patch extended from the one in bug 177789. Now includes xptcall patches. With this, registration of components finishes, but browser still does not come up. Still to do: 1) How do we link to GreEscape (in file nsDeviceContextSpecOS2.cpp)? 2) Find a good place to put "#define strcmpi stricmp", so we don't have to include it in multiple files throughout the tree. 3) Testing. Need to make sure tests in dist/bin perform as they do on other platforms. 4) Any other TODO item in the patch

Does testXPC work OK? Have your run the nspr tests? That's where I always start when the browser doesn't come up. 1) Where is GreEscape? 2) Here it's at the top of _os2.h in nspr, but I don't know how far that reaches.

There's no good central header file to add the strcmpi defines to. Somewhere in NSPR would probably be best (since everything depends upon NSPR) but it really doesn't belong there. LDAP gets around this problem by adding the define to its portable.h file. We probably shouldn't use that though. So how about just adding it to configure.in ? AC_DEFINE(strcmpi,stricmp)

Fixes GreEscape issue, and finds better place for strcmpi functions.

Actually, the GreEscape solution was to link to one of the libraries included in the Toolkit (os2386.lib). So if you don't have the toolkit, you'll have to patch this. Of course, then printing won't work for you, assuming we ever get Mozilla to come up in the first place!

The following tests fail on OS/2 but work on a Linux build: TestFileTransport.exe lots.exe (works on Mozilla build with VACPP) proxytests.exe NSPR tests do not build right now, but I'm working on it.

Strange issue: GCC "-pipe" support gets set by the configure script for Mozilla, but not for NSPR or LDAP. The code looks nearly identical between the three; even if I make the latter two look like the working script, they still fail. Any ideas as to why this would be happening?

Can't really say anything without knowing exactly what's failing and how. Here I have SET GCCOPT=-pipe in config.sys so that all compilation uses pipes. You could just add that to setmozenv.cmd.

I'd forgotten about the env variable. I just thought that it was odd. The main configure script outputs "Checking for -pipe support....yes", while the other two say "...no". Nothing in config.log. No failure case. Nothing.

The difference appears to be that mozilla/configure uses '$AS -v' to test for GNU as & the rest use '$AS -V'.

Yes, that seems to be it. The configure scripts define $AS to be gcc, which doesn't like "-V" with no arguments. If I change those references in nspr and c-sdk to "-v", I get the pipe support.

Link in mouse pointers (such as hand). Build installer. General code cleanup.

Define BSD_SELECT in the correct place.

Includes the following changes: * fixed dependencies * proper weaksyms.omf support * some general cleanup * took full xptcall changes from bug 134113 For the xptcall changes, I had to change ".section \".text\"\n\t" to ".text\n\t" (assembler gave error on '.section') in xptcstubs_gcc_x86_unix.cpp. This should work on linux, since xptcinvoke_gcc_x86_unix.cpp didn't use '.section'. Can anyone comment on this?

The patch had the following problem from where I applied it to the pull on 3/14-3/15 time frame. *************** *** 1245,1279 **** fi # EMX/GCC build - if test "$GNU_CC"; then - _PEDANTIC='' - AR=emxomfar - AR_FLAGS='-p256 r $@' - CFLAGS="-Zmtd -Zomf $CFLAGS" - CXXFLAGS="-Zmtd -Zomf $CXXFLAGS" - DSO_LDOPTS='-Zomf -Zdll -Zmt -Zcrtdll -Zlinker /NOO' - BIN_FLAGS='-Zlinker /PM:VIO -Zlinker /ST:0x30000' - IMPLIB='emximp -o' - FILTER='emxexp' - LIB_PREFIX=lib AC_DEFINE(OS2) AC_DEFINE(XP_OS2_EMX) AC_DEFINE(OS2EMX_PLAIN_CHAR) - MOZ_COMPONENT_NSPR_LIBS='-L$(DIST)/lib $(NSPR_LIBS)' - MOZ_COMPONENT_XPCOM_LIBS='-L$(DIST)/lib $(DIST)/lib/xpcom.lib' - XPCOM_LIBS='-L$(DIST)/lib -lxpcom' - MOZ_JS_LIBS='$(DIST)/lib/libmozjs.lib' - MOZ_COMPONENT_XPCOM_LIBS='$(DIST)/lib/libxpcom.lib' - XPCOM_LIBS='$(DIST)/lib/libxpcom.lib' - MOZ_JPEG_LIBS='$(DIST)/lib/libmozjpeg.$(LIB_SUFFIX)' - MOZ_ZLIB_LIBS='$(DIST)/lib/libmozz.$(LIB_SUFFIX)' - MOZ_PNG_LIBS='$(DIST)/lib/libmozpng.$(LIB_SUFFIX)' - MOZ_MNG_LIBS='$(DIST)/lib/libmozmng.$(LIB_SUFFIX)' - fi # Visual Age C++ build - if test "$VACPP" = "yes"; then - # MOZ_BUILD_ROOT="$ROOT"`pwd -D` AR=-ilib AR_FLAGS='/NOL /NOI /O:$(subst /,\\,$@)' AR_LIST='/L' --- 1239,1274 ---- fi # EMX/GCC build + if test -n "$GNU_CC"; then + # AC_DEFINE(USE_OS2_TOOLKIT_HEADERS) AC_DEFINE(OS2) AC_DEFINE(XP_OS2_EMX) AC_DEFINE(OS2EMX_PLAIN_CHAR) + AR=emxomfar + AR_FLAGS='-p256 r $@' + CFLAGS="$CFLAGS -Zmtd -Zomf" + CXXFLAGS="$CXXFLAGS -Zmtd -Zomf" + DSO_LDOPTS='-Zdll' + BIN_FLAGS='-Zlinker /ST:0x30000' + IMPLIB='emximp -o' + FILTER='emxexp -o' + MOZ_DEBUG_FLAGS="-g -fno-inline" + MOZ_OPTIMIZE_LDFLAGS="-Zlinker /EXEPACK:2 -Zlinker /PACKCODE -Zlinker /PACKDATA" + MOZ_WIDGET_TOOLKIT_LDFLAGS='-lwdgt$(MOZ_WIDGET_TOOLKIT)' + MOZ_GFX_TOOLKIT_LDFLAGS='-lgfx_$(MOZ_WIDGET_TOOLKIT)' + + if test -z "$EMXOMFLD_LINKER"; then + # using LINK386.EXE + DSO_LDOPTS="$DSO_LDOPTS -Zlinker /NOO" + fi + + # GCC for OS/2 currently predefines these, but we don't want them + _DEFINES_CFLAGS="$_DEFINES_CFLAGS -Uunix -U__unix -U__unix__" + _DEFINES_CXXFLAGS="$_DEFINES_CXXFLAGS -Uunix -U__unix -U__unix__" # Visual Age C++ build + elif test "$VACPP" = "yes"; then + OBJ_SUFFIX=obj AR=-ilib AR_FLAGS='/NOL /NOI /O:$(subst /,\\,$@)' AR_LIST='/L' Seems to be triggered by this additional line in the original that was not removed nor shown as being left MOZ_XPCOM_OBSOLETE_LIBS='-L$(DIST)/lib $(DIST)/lib/xpcomct.lib' At least that was the only thing I could see that would have caused a rejection. Andy

A lot of changes went in to the trunk this weekend, and seem to have broken the patches. I'll try to get some new ones this afternoon.

This is the only one I had problems with. I removed that line and shouldn't have. MOZ_XPCOM_OBSOLETE_LIBS='-L$(DIST)/lib $(DIST)/lib/xpcomct.lib'

Can we just fix the strcmpi and itoa in the tester/common files if it is incorrect syntax?

I've checked in about half of these changes (the OS/2 specific stuff) primarily addressing the strcmpi/stricmp and itoa/_itoa Diff should be much smaller now.

Can you break future patches into their respective component pieces? The respective owners should review those patches (or at least be aware of them).

Diff against latest trunk.

Comment on attachment 117930 [details] [diff] [review] central make/configure changes (checked in) r=cls

Comment on attachment 117939 [details] [diff] [review] xpfe changes (checked in) r=cls

Comment on attachment 117940 [details] [diff] [review] misc os2 changes (checked in) e=xla

Seawood: Thanks for asking for more reviews. I step out for a bit, and this is what I come back to! Don't check these in, though. This may break the Visual Age build. Kaply will take care of the checkins. Thanks.

Comment on attachment 117936 [details] [diff] [review] gfx changes (checked in) >- PSZ pszDocName = title != nsnull?title:"Mozilla Document"; >+ PSZ pszDocName; >+ if (title != nsnull) { >+ pszDocName = title; >+ } else { >+ pszDocName = new char[17]; >+ strcpy(pszDocName, "Mozilla Document"); >+ pszDocName[17] = '\0'; >+ } Is there a better way to do this? Maybe a const string for "Mozilla Document" - that new seems expensive if it ever happens. (DosAllocMem((PPVOID)&pNewDrivData,buflen,fALLOC)) >- return(DPDM_ERROR); >+ return(PR_FALSE); This should be return FALSE - the function is BOOL

Comment on attachment 117933 [details] [diff] [review] xpcom changes (checked in) if Mike is okay with this changes i am.

Comment on attachment 117934 [details] [diff] [review] js changes (checked in) >Index: js/src/jsnum.c >=================================================================== >RCS file: /cvsroot/mozilla/js/src/jsnum.c,v >retrieving revision 3.48 >diff -u -r3.48 jsnum.c >--- js/src/jsnum.c 11 Mar 2003 03:27:07 -0000 3.48 >+++ js/src/jsnum.c 20 Mar 2003 18:55:09 -0000 >@@ -438,7 +438,7 @@ > > static jsdouble NaN; > >-#if !defined __MWERKS__ && defined XP_PC && (defined _M_IX86 || (defined __GNUC__ && !defined(__MINGW32__))) >+#if !defined __MWERKS__ && defined XP_PC && (defined _M_IX86 || (defined __GNUC__ && !defined(__MINGW32__) && !defined(__EMX__))) > > /* > * Set the exception mask to mask all exceptions and set the FPU precision How about we finally bite the bullet on formatting and break that overlong line up, like so (ignore column number header line immediately below)? 1234567890123456789012345678901234567890123456789012345678901234567890123456789 0 #if !defined __MWERKS__ && \ defined XP_PC && \ (defined _M_IX86 || \ (defined __GNUC__ && !defined(__MINGW32__) && !defined(__EMX__))) Note the backslashes in column 79 (not in column 80, numbering from 1, to avoid Emacs wrapping the line prematurely). I wonder why the defined XP_PC clause is second -- I'd have put it first. If you agree, transpose it with the !defined __MWERKS__ test. This preprocessor code mixes defined FOO with defined(FOO) style -- please unify, your taste. I avoid parens when using the defined operator, myself. Pick these nits and r=brendan@mozilla.org. /be

Comment on attachment 117938 [details] [diff] [review] xpinstall changes (checked in) >+ _getcwd2(componentPath, MAX_PATH); >+ for (int i = 0; i < strlen(componentPath); i++) { Please do the strlen() once rather than each time through the loop. sr=dveditz with that change.

Kaply: Can you add "(checked in)" to the name of every patch that you check in? Thanks.

Comment on attachment 118332 [details] [diff] [review] plugin changes v1.1 (checked in) r=peterl

Comment on attachment 118332 [details] [diff] [review] plugin changes v1.1 (checked in) This "common" code (which seems to be built only on OS/2) doesn't look very portable, but sr=dbaron.

Remove unnecessary define

Comment on attachment 118427 [details] [diff] [review] xptcall changes v1.1 (checked in) r=dbradley

They're all in. Marking fixed.