215581 - Build with GCC 3.2.2 for OS/2

Status: RESOLVED FIXED

(SeaMonkey :: Build Config, defect)

Description

[jhp (no longer active)]

GCC v3.2.2 includes many updates over v3.2.1 (currently used on the trunk
tinderbox).  The big changes in v3.2.2 release are making it work better with
existing OS/2 compilers and compilers, and removing the dependency on the EMX
environment.

Comment 1

[jhp (no longer active)]

Attachment: NSPR patch v1

Some of the changes in this patch (and others) includes support for the leading
underscore in function names and support for better networking.  This patch
also includes a VAC legacy layer, so that plugins and other programs linked
against the Visual Age built NSPR can also use this GCC built NSPR.

Comment 2

[jhp (no longer active)]

Attachment: LDAP patch v1

Comment 3

[jhp (no longer active)]

Attachment: XPCOM patch v1

Like NSPR, this patch also includes some changes for a VAC legacy interface. 
Specifically, this is for the IBM Java 1.3.1 plugin, which was built with
Visual Age and linked against xpcom.dll.

Comment 4

[jhp (no longer active)]

Attachment: NSS patch v1

Comment 5

[jhp (no longer active)]

Attachment: Javascript patch v1

This patch is the trickiest to deal with.  It turns out that the Presentation
Manager on OS/2 can sometimes change the floating point control word.  This
means that on OS/2, we cannot just rely on the _control87 call in jsnum.c,
since any call to PM after this may change the fp control word.  Rather, I have
added similar calls to the strtod or dtoa functions.  It's not pretty, but for
the most part, it works.  I am still investigating whether this is really the
best option, though.

Comment 6

[jhp (no longer active)]

Attachment: Seamonkey patch v1

This patch has all the remaining changes in Seamonkey.

Comment 7

[Mark Smith [:mcs]]

Comment on attachment 129461 [details] [diff] [review]
LDAP patch v1

The LDAP changes look OK.

Comment 8

[Julien Pierre]

Comment on attachment 129460 [details] [diff] [review]
NSPR patch v1

Patch looks good

Comment 9

[Brendan Eich [:brendan]]

Comment on attachment 129464 [details] [diff] [review]
Javascript patch v1

>Index: js/src/jsdtoa.c
>===================================================================
>RCS file: /cvsroot/mozilla/js/src/jsdtoa.c,v
>retrieving revision 3.24
>diff -u -r3.24 jsdtoa.c
>--- js/src/jsdtoa.c	3 Apr 2003 19:35:20 -0000	3.24
>+++ js/src/jsdtoa.c	6 Aug 2003 21:22:19 -0000
>@@ -1229,6 +1229,24 @@
> 
> /* nspr2 watcom bug ifdef omitted */
> 
>+#ifdef XP_OS2
>+/* On OS/2, some system function calls seem to change the FPU control word,

How about an XXX on the first line of this comment?  Axe trailing spaces too,
while you are here.

>+++ js/src/jsnum.c	6 Aug 2003 21:22:19 -0000
>@@ -418,10 +418,10 @@
> static jsdouble NaN;
> 
> 
>-#if (defined XP_WIN || defined XP_OS2) &&                                     \
>+#if defined XP_WIN &&                                     \

Please keep the backslashes lined up.

>     !defined __MWERKS__ &&                                                    \
>     (defined _M_IX86 ||                                                       \
>-    (defined __GNUC__ && !defined __MINGW32__ && !defined __EMX__))
>+     (defined __GNUC__ && !defined __MINGW32__))

Thanks for fixing that indentation glitch!

I still wonder why only OS2 has such a random FPU mode programming model.  Any
chance of a PM fix?

/be

Comment 10

[jhp (no longer active)]

> How about an XXX on the first line of this comment?

Sorry, have to ask about this:  what is the purpose of the "XXX"?  Is this to
denote disgusting hacks?

> I still wonder why only OS2 has such a random FPU mode programming model.  Any
chance of a PM fix?

Yeah, I'm still wondering myself!  And it doesn't look like this will ever get
fixed in PM.

Comment 11

[timeless]

brendan: have you forgotten all the fun dbradley has encountered when mscom or
something changes the fpu mode?

Comment 12

[David Bradley]

The details were that when some software was installed, JS Virtual Pager was
one, calling CoInitialize returned with the FPU set to different, I think
higher, precision. I agree it seems really strange that this isn't preserved
across this call. Honestly I never really understood how that impacted
CoInitialize. In any case it's not just an OS/2 issue, but a Windows issue as
well. Logic was added to the JS floating point initialization logic to
initialize it to the set precision. This was addressed in bug 160602.

Comment 13

[Brendan Eich [:brendan]]

timeless: I remember everything, but the fact is that the bug dbradley cites,
bug 160602, was fixed without adding calls to FIX_FPU all the time.

mkaply: yes, XXX denotes disgusting hacks and other things that should be
revisited from time to time.

/be

Comment 14

[David Bradley]

IIRC _control87 is not a trivial call in some implementations, at least on
Windows. That was why it was decided to go with setting it in the initialization
logic. That combined with the fact that on Windows the source of it getting
changed was CoInitialize.

If PM is sporadically changing this over the life of the process then what was
done in the initialization code isn't going to be sufficient. But I'm not sure
if you really want the perf hit of calling it on every call of JS_strtod.

I still wonder if it wouldn't be better to have JS_strtod handle the higher
precision, but I'm not sure if that might be a worse performance issue for the
algorithm.

Comment 15

[jhp (no longer active)]

Attachment: LDAP patch v1.1

GCC 3.2.2 Beta 1 changes: remove -Zmtd

Comment 16

[jhp (no longer active)]

Comment on attachment 131099 [details] [diff] [review]
LDAP patch v1.1

Carrying forward mcs' r=

Comment 17

[jhp (no longer active)]

Attachment: Seamonkey patch v1.1

GCC 3.2.2 Beta 1 changes: remove -Zmtd; increase stack size; remove
weaksyms.omf hacks; added modules/plugin/samples changes

Comment 18

[jhp (no longer active)]

Attachment: NSS patch v1.1

GCC 3.2.2 Beta 1 changes: remove -Zmt* and -Zcrtdll; remove LINK386 lines

Comment 19

[jhp (no longer active)]

Attachment: NSPR patch v1.1

GCC 3.2.2 Beta 1 changes: remove -Zmtd; increase stack size

Comment 20

[jhp (no longer active)]

Comment on attachment 131102 [details] [diff] [review]
NSPR patch v1.1

carry over jpierre's r=

Comment 21

[jhp (no longer active)]

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

Comment 22

[knut st. osmundsen]

I've looked thru the latest patches, and all find a little problem with your
stack changes. Do you have a good reason for using a thread 1 stack size (for
mozilla.exe in particular) which is less than half of the one used by the VACPP
and MSVC builds? I would recommend to use /sT:0x100000 as VACPP and MSVC does.

Comment 23

[Wan-Teh Chang]

Comment on attachment 131101 [details] [diff] [review]
NSS patch v1.1

r=wtc.	I've checked in this patch on the NSS trunk (NSS 3.9),
NSS_3_8_BRANCH (NSS 3.8.2), and NSS_CLIENT_TAG (Mozilla 1.6 alpha).

Comment 24

[jhp (no longer active)]

Attachment: NSPR patch v1.2

Redid the code to check for legacy (Visual Age-built) plugins; added ifdefs in
order to make IPC work.

Comment 25

[jhp (no longer active)]

Attachment: XPCOM patch v1.1

Fully qualify the plevent.c path.

Comment 26

[jhp (no longer active)]

Attachment: Seamonkey patch v1.2

Update to trunk; make legacy IDL only export for OS/2

Comment 27

[jhp (no longer active)]

Attachment: NSPR patch v1.3 (checked in after editing)

Remove check for underscore in prlink.c, as it is not necessary and redundant.

Comment 28

[Andy Willis (abwillis)]

Looking at the nspr patches 1.1 was correct but 1.2 and 1.3 have incorrect paths:
Index: pr/include/prio.h
===================================================================
RCS file: /cvsroot/mozilla/nsprpub/pr/include/prio.h,v
retrieving revision 3.31.4.3
diff -u -r3.31.4.3 prio.h
--- pr/include/prio.h	27 Nov 2002 03:08:27 -0000	3.31.4.3
+++ pr/include/prio.h	11 Sep 2003 21:47:28 -0000

pr should be prefaced with nsprpub throughout the entire patch.
I and Dimitrios have both got corrected versions that could be uploaded.
Andy
Andy

Comment 29

[Wan-Teh Chang]

Comment on attachment 131339 [details] [diff] [review]
NSPR patch v1.3 (checked in after editing)

1. pr/include/prio.h

>+ #ifdef XP_OS2
>+        char path[108];                 /* null-terminated pathname */
>+ #else
>         char path[104];                 /* null-terminated pathname */
>+ #endif

Is it necessary for the 'path' buffer to be 108 char long?
Or is it because that's the size of that buffer in the
sockaddr_un structure buffer on OS/2?

2. pr/include/prtypes.h

Is it necessary to remove the XP_OS2_VACPP stuff?  Are
you trying to make sure that people don't build NSPR with
VAC?

3. pr/src/md/os2/os2misc.c

It seems that _PR_DetachOS2Process simply can't be implemented
on OS/2.  If so, maybe that function should set the error code
to PR_NOT_IMPLEMENTED_ERROR and return PR_FAILURE?

Comment 30

[Wan-Teh Chang]

Comment on attachment 131339 [details] [diff] [review]
NSPR patch v1.3 (checked in after editing)

I've checked in most of this patch on the NSPR trunk (NSPR
4.5) and NSPRPUB_PRE_4_2_CLIENT_BRANCH (Mozilla 1.6 alpha),
with the following exceptions:

1. The three files I asked about in my previous comment.

2. I renamed extradefs.os2 to os2extra.def and os2VACLegacy.s
to os2vaclegacy.s.

3. I edited a few files.  In particular, I'd like you to
test nsprpub/pr/tests/dll/Makefile.in and make sure that
my changes to that file are fine.

Comment 31

[jhp (no longer active)]

> Is it necessary for the 'path' buffer to be 108 char long?
> Or is it because that's the size of that buffer in the
> sockaddr_un structure buffer on OS/2?

Yes.

> 2. pr/include/prtypes.h
> Is it necessary to remove the XP_OS2_VACPP stuff?  Are
> you trying to make sure that people don't build NSPR with
> VAC?

Our plan is to eventually remove all VAC specific code from the tree, with
Mozilla 1.4 being the last milestone that can be built with VACPP.  The VACPP
compiler suite is no longer supported nor is it available;  GCC is up to date
and free.
I had been playing around with the removed code at the beginning of moving up to
GCC 3.2.2, but in the end none of it was necessary, so I removed it.

> 3. pr/src/md/os2/os2misc.c
> It seems that _PR_DetachOS2Process simply can't be implemented
> on OS/2.  If so, maybe that function should set the error code
> to PR_NOT_IMPLEMENTED_ERROR and return PR_FAILURE?

Your way sounds good.

Comment 32

[Wan-Teh Chang]

Comment on attachment 131339 [details] [diff] [review]
NSPR patch v1.3 (checked in after editing)

I've reviewed this patch and checked it after editing
on the NSPR trunk (NSPR 4.5) and NSPRPUB_PRE_4_2_CLIENT_BRANCH
(Mozilla 1.6 alpha).

Comment 33

[Dimitrios Bogiatzoules]

As far as I can see the most of the patches are checked in. A comparison of the
files in the trunk and each patch shows the following patches missing: 

mozilla/modules/plugin/base/public/nsILegacyPluginWrapperOS2.idl
mozilla/netwerk/dns/src/nsDnsService.cpp,v 
mozilla/xpcom/build/nsOS2VACLegacy.cpp
mozilla/xpinstall/wizard/os2/uninstall/parser.c,v

I also couldn't find out were nsILegacyPluginWrapperOS2.h has gone.

Am I right, that without the legacy stuff the FLASH etc. plugins wouldn't work?

Comment 34

[knut st. osmundsen]

Yes, the legacy stuff, including the any left out patching in the
mozilla/module/plugin/ tree is related to OJI and Flash plugins. The legacy
hacks in XPCOM is only related to IBM OJI plugins begin linked with XPCOM.lib.

Comment 35

[Dimitrios Bogiatzoules]

OK! Do I need then this (from Seamonkey patch v1.2): 
  mozilla/modules/plugin/base/public/nsILegacyPluginWrapperOS2.idl
and this (but were is it defined? I couldn't find it anywhere!)
  nsILegacyPluginWrapperOS2.h 
which is included in
  /mozilla/modules/plugin/base/src/ns4xPluginInstance.cpp
  /mozilla/modules/plugin/base/src/nsPluginHostImpl.cpp

Comment 36

[(default assignee for unassigned bugs. does not receive bugmail)]

Mass reassign of Build/Config bugs to Leaf.

Comment 37

[Andy Willis (abwillis)]

Here are some changes I suggest to the setmozenv script.  These should be remmed
out by default but be in there for those like myself that do not put things off
the root but have no reason to set all the environment variables globally.  It
just puts all the sets together so they can be easily updated.

'set MOZENV=1'

/* MY PATHS */
'SET PERLLOC=E:\COMPILERS\PERL'
'SET GCCDIR=E:\COMPILERS\GCC322'
'SET EMX=E:\COMPILERS\EMX'
/* 'SET MOZTOOLS=moztools' */
/* 'SET VACPP365=E:\COMPILERS\IBMCXXO' */
/* 'SET GLIB=glib' */
/* 'SET AUTOCONF=autoconf' */
/* 'SET LIBIDL=libidl' */
'SET TOOLKIT=E:\TOOLKIT'
/* END MY PATHS */

/* Figure out what drive the utility was run on and set it as ROOT */

Andy

Comment 38

[jhp (no longer active)]

OK, the remaining plugin patches have been checked in, so marking this bug fixed.

LDAP was checked in to client branch, but not into trunk.  I'll open up another
bug for that.

Comment 39

[mike.hitchcock]

Tested with Build 2003110412 mozilla 1.6a for OS/2 with GCC3.22 & li04fix from
innotek.

Initial load ok - imports from Netscape ok browser will load web pages.

Exit program

try to start mozilla again - logo displays then error SYS3183 error in MOZJS.DLL
at 1e08122d

Browser fails to load

Comment 40

[jhp (no longer active)]

Mike Hitchcock: please see bug 224487.

Comment 41

[mike.hitchcock]

The solution of deleting REGISTRY.DAT give in 224487 has no effect on my system.

still reports error SYS3183 on new browser load after deletion