454956 - OS/2 build broken with GCC 3.4.6 or later

Status: RESOLVED FIXED

(Firefox Build System :: General, defect)

Description

[Paul Smedley]

User-Agent:       Mozilla/5.0 (OS/2; U; Warp 4.5; en-US; rv:1.8.1.16) Gecko/20080715 PmWFx/2.0.0.16
Build Identifier: Mozilla/5.0 (OS/2; U; Warp 4.5; en-US; rv:1.8.1.16) Gecko/20080715 PmWFx/2.0.0.16

Building current OS/2 cvs fails with GCC 3.4.6 
error:
../../../dist/include/widget/nsIDragSessionOS2.h:99: error: extra `;'

Line 62 of the above file has a semi-colon at the end of the #define which is unnecessary.

Additionally, line 853 of widget\src\os2\nsRwsService.cpp also has an unnecessary ; which causes build breakage with GCC 3.4.6

Reproducible: Always

Steps to Reproduce:
1. Compile using GCC 3.4.6 - available from http://downloads.smedley.info/gcc-3.4.6-os2-20080912.zip - updated setmozenv available from http://smedley.info/setmozenv_gcc346.cmd

Actual Results:  
Build breakage with errors mentioned in details

Expected Results:  
The build to work :)

Comment 1

[Peter Weilbacher]

Paul, thanks for filing this. And especially your work on GCC!
I hope I get around to trying the new version tonight (European time).

Comment 2

[Peter Weilbacher]

Attachment: [checked in] fix as suggested

Even before trying to build on OS/2, this is the patch.

Comment 3

[Walter Meinl]

Comment on attachment 338287 [details] [diff] [review]
[checked in] fix as suggested

Peter, I am currently far away from my build machine, so I couldn't try it for real, but the patch looks good. I am guessing that you cannot await trying gcc-3.4.6 so  this will be checked by you.

Comment 4

[Peter Weilbacher]

After noticing that there is an "s" too much in the URL in comment 0 (download or no host name work), I see that the package is still missing some stuff. I commented more on this in gmane.org.netlabs.libc.user newsgroup.

So for the moment I am just going to verify that removing the semicolons doesn't break GCC 3.3.5 and then check them into Mercurial and CVS trunk.

Comment 5

[Peter Weilbacher]

Comment on attachment 338287 [details] [diff] [review]
[checked in] fix as suggested

OK, GCC 3.3.5 doesn't show any problems, so I have pushed this to mozilla-central (changeset d5c3d6b6291f) and CVS trunk (just in case we want to compile Firefox 3.0.x with GCC 3.4 at some point).

I'll leave this bug open still, in case we discover other problems with GCC 3.4 as we go on.

Comment 6

[Peter Weilbacher]

With Paul's newest build I now get

<path>/mozilla/toolkit/xre/nsAppRunner.cpp:
   In function `nsresult LaunchChild(nsINativeAppSupport*, PRBool)':
<path>/mozilla/toolkit/xre/nsAppRunner.cpp:1611:
   error: `_execv' was not declared in this scope
<path>/mozilla/toolkit/xre/nsAppRunner.cpp:1611:
   warning: unused variable '_execv'

and later

<path>/mozilla/toolkit/xre/nsNativeAppSupportOS2.cpp:
   In function `PRBool StartOS2App(int, char**)':
<path>/mozilla/toolkit/xre/nsNativeAppSupportOS2.cpp:1825:
   error: ISO C++ forbids cast to non-reference type used as lvalue

The first can be fixed by changing the two instances of __GNUC_MINOR__ == 3 to __GNUC_MINOR__ >= 3, the second by changing the cast to a (PSZ) on the right.

Comment 7

[Peter Weilbacher]

Later I get

In file included from <path>/mozilla/security/nss/cmd/lib/secutil.c:52:
<path>/mozilla/security/nss/cmd/lib/secutil.h:454:
   error: conflicting types for 'ffs'
<path>/mozilla/security/nss/cmd/lib/secutil.h:454:
   error: conflicting types for 'ffs'

Hmm, shouldn't one of the error lines normally list the other definition?
Anyway, also simply fixed by adding another ifdef check.

Comment 8

[Peter Weilbacher]

This ffs thing is really weird, because it is defined in strings.h which is included from the GCC 3.3.5 directory and in the preprocessed source I can see
   int ffs(int);
[...]
   extern int ffs(unsigned int i);
for both 3.3.5 and 3.4.6. I guess GCC 3.4 got stricter in this regard.


Next issue:
wrap_VFTs.h from ipluginw needs to be edited to throw out the defaults of the function parameters in the declarations. This brings me through the build, but I guess it will have bad effects later, so maybe we need to add the default values somewhere else (in ipluginw?).

Comment 9

[Peter Weilbacher]

My current patch to get through the build is at
http://hg.mozilla.org/users/mozilla_weilbacher.org/m-c_Mq/file/d4d4a068189d/bug454956_gcc346_build_fixed.diff

But on startup I get 100% CPU usage (even when removing ipluginw.dll before) with SM 20080920025700. In a debug build I see
   WARNING: running socket transport thread without a pollable event:
   file <path>/netwerk/base/src/nsSocketTransportService2.cpp, line 400
When running with
   NSPR_LOG_MODULES=nsSocketTransport:5
   NSPR_LOG_FILE=nsSocketTransport.log
I get recurring output of
   2[20101100]: STS poll iter [0]
   2[20101100]:   calling PR_Poll [active=0 idle=0]
   2[20101100]:     timeout = 0 milliseconds
   2[20101100]:     ...returned after 0 milliseconds
   2[20101100]:   PR_Poll error [-5999]
until I kill the process. The code above the warning says something about the loopback interface on OS/2, but that is working fine here...

As FF from CVS works for Paul, this could either be something that changed in Mercurial, some local problem, or something specific to comm-central builds (TB from the same sources has the same problem).

Comment 10

[Peter Weilbacher]

Just to note that a build using GCC 3.3.5 (with the two extra patches) from the same Mercurial sources as the 3.4.6 build works fine...

Comment 11

[Paul Smedley]

I'll try get a git build working here and see how I go.  Some of your patches have a different solution to what I used in CVS, and I also see a couple of extra changes (ie npshell.cpp, plugin.cpp & plugin.h) that I didn't need to make.

I'll also try run a diff tonight of my cvs changes for comparison.

Comment 12

[Dave Yeo]

I finally got around to building Seamonkey. Only patch applied was your patch in comment #9. The build seems to be working fine, using it to type this in.
Haven't tried it with my profile yet as this is running with set MOZILLA_HOME= and -no-remote.
Source was pulled about noon PDT.

Comment 13

[Dave Yeo]

While not qualified to comment on the patch to a/modules/plugin/os2wrapper/wrap_VFTs.h and toolkit/xre/nsNativeAppSupportOS2.cpp the rest of the patch looks good besides a white space change? at line 42,43. Since this is all OS/2 code it would be nice to get it checked in.

Comment 14

[Paul Smedley]

Dave, was your build cvs or git? My cvs build works, Peter's git one doesn't.

Comment 15

[Dave Yeo]

Mine was Mercurial, Mozilla/5.0 (OS/2; U; Warp 4.5; en-US; rv:1.9.1b1pre) Gecko/20080921174828 SeaMonkey/2.0a1pre
The only needed changes were a configure script deleted to force autoconf and a rexx script needs its line endings changed as well as Peter's patch.
Also I built gcc 3.4.6 from source with your latest patch and instructions.

Comment 16

[Peter Weilbacher]

I found out that the difference between a 3.3.5-based build and a 3.4.6 based one is that in the latter the call to bind() fails. This one:

http://hg.mozilla.org/mozilla-central/annotate/93928936b1ab/nsprpub/pr/src/md/os2/os2sock.c#l359

That directly causes the WARNING that I mentioned in comment 9. I compared the pre-processed source of os2sock.c but that showed me no significant differences. (The only differences really are #undefs that I think GCC 3.3.x just doesn't show with gcc -dD -E.)

Copying in nspr4.dll from the GCC 3.3.5 build into the directory of the 3.4.6 build helps, it starts nicely.

Comment 17

[Walter Meinl]

I've now built also a Firefox and Seamonkey using GCC-3.4.6 from Paul's ZIP file installed in /usr/local. Both come up immedeately and run fine. The firefox build was checked out two days ago and shows peaks of 100% processor usage when loading a page, the seamonkey build checked out yesterday (09-30) runs even smoother, only occasionally high peaks when loading pages. I applied only the (modified as some parts were already checked in) patch mentioned in comment 9. Both builds were compiled against the newest version of fontconfig checked out with hg from Peter's repository.

Peter, the problems with nspr4.dll somehow remind me of a problem I had long time ago (find in the newsgroup the thread "Build whoes") when I had a messed up setup in setmozenv.cmd regarding
'set LIBRARY_PATH' and 'set LIB' (the latter is not set in Paul's setmozenv_gcc346.cmd.
Here is the diff of my setmozenv_gcc335.cmd vs. setmozenv_gcc346.cmd
In both settings I took care that %GCCDIR2%/lib/tcpipv4 and %GCCDIR%\lib\tcpip4 remained the first entry of the setting (GCCDIR is usr in my case)
-'SET LIBRARY_PATH=%GCCDIR2%/lib/tcpipv4;%GCCDIR2%/lib/gcc-lib/i386-pc-os2-emx/3.3.5;%GCCDIR2%/lib;%TOOLKIT2%/lib;'
-'SET LIB=%GCCDIR%\lib\tcpipv4;%GCCDIR%\lib;%TOOLKIT%\lib;'
+'SET LIBRARY_PATH=%GCCDIR2%/lib/tcpipv4;%GCCDIR2%/local/lib/gcc-lib/i386-pc-os2-emx/3.4.6;%GCCDIR2%/lib;%TOOLKIT2%/lib;'
+'SET LIB=%GCCDIR%\lib\tcpipv4;%GCCDIR2%\local\lib;%GCCDIR%\lib;%TOOLKIT%\lib;'

Comment 18

[Walter Meinl]

I was again able to compile this time with Paul's new build 20080930 using the trivial patch for bug458113 and the patch from comment 9 a useful libxul-enabled firefox and a shared seamonkey. However with the same sources I tried to build a static thunderbird but failed in linking the static exe:
weakld: error: Unresolved symbol (UNDEF) '___popcountsi2'.
weakld: info: The symbol is referenced by:
    E:\mozbuild\mozilla\gfx\cairo\cairo\src\mozcairo.lib(cairo-image-surface.o)
Ignoring unresolved externals reported from weak prelinker.

E:\mozbuild\mozilla\gfx\cairo\cairo\src\mozcairo.lib(cairo-image-surface.o) : error LNK2029: "___popcountsi2" : unresolved external
popcountsi2 is a symbol from gcc. Thus, could it be that we are missing somewhere a -lgcc in static builds? I couldn't find it in the tb build log (but found it in the logs when linking xul.dll of ff or thebes.dll and gkgfxthb.dll of seamonkey)

Comment 19

[Peter Weilbacher]

Walter, does your config/autoconf.mk in the object tree contain -lgcc? I'm pretty sure that xul.dll linking uses MOZ_CAIRO_LIBS and should hence make use of that extra flag.
Perhaps this should be added to MOZ_CAIRO_LIBS directly instead of making use of CAIRO_FT_LIBS but I don't really see what difference that should make in the end...

(Didn't get a chance to try your setup suggestions yet.)

Comment 20

[Peter Weilbacher]

OK, I finally got builds of SM, TB, and FX to run through, with GCC 3.4.6 for the time being. Indeed my LIBRARY_PATH for the 3.4.6 setup was messed up and contained a non-existing tcpipv4 directory. I did not observe any problems linking xul.dll in the Firefox build.

Comment 21

[Peter Weilbacher]

Hmm, but most (all?) binaries except thebes.dll are now linked against GCC346.DLL and hence require that to run.

And actually we cannot link anything with -lgcc because that statically links code into the binaries which is not tri-licensed or at least not MPL-compatible (I couldn't actually find which license applies to GCC346 or its static counterpart, but I guess its LGPL only). So we need a new libc, too, or require GCC<version>.DLL until we have that.

Comment 22

[Peter Weilbacher]

Attachment: [checked in] part 2 of the fix series

OK, so I split off the NSS issue into another bug. If we leave out the -lgcc trick for now, then this is what I think should get in soon.

Comment 23

[Walter Meinl]

Comment on attachment 342689 [details] [diff] [review]
[checked in] part 2 of the fix series

The patch is identical with that I'm using (except the configure.in and nss changes) for several days. With gcc-3.4.6 I get a working java

Comment 24

[Walter Meinl]

(In reply to comment #19)
> Perhaps this should be added to MOZ_CAIRO_LIBS directly instead of making use
> of CAIRO_FT_LIBS but I don't really see what difference that should make in 
configure.in
cairo-os2)
    MOZ_WIDGET_TOOLKIT=os2
    MOZ_GFX_TOOLKIT=cairo
    TK_CFLAGS='$(MOZ_CAIRO_CFLAGS)'
    TK_LIBS='$(MOZ_CAIRO_LIBS) -lgcc'
    ;;
worked for static thunderbird. -lgcc is used only when finally linking the static exe. Not yet tested with firefox or seamonkey.
Would we be able (from the view of license) to use -lgcc by adding it to OS_LIBS?

Comment 25

[Peter Weilbacher]

Comment on attachment 342689 [details] [diff] [review]
[checked in] part 2 of the fix series

OK, pushed as http://hg.mozilla.org/mozilla-central/rev/007ce14e8921

Java and Flash work for me, too (although YouTube crashes FF).

Maybe we have to revisit wrap_VFTs.h for a later GCC.

Comment 26

[Peter Weilbacher]

(In reply to comment #24)
> configure.in
> cairo-os2)
>     MOZ_WIDGET_TOOLKIT=os2
>     MOZ_GFX_TOOLKIT=cairo
>     TK_CFLAGS='$(MOZ_CAIRO_CFLAGS)'
>     TK_LIBS='$(MOZ_CAIRO_LIBS) -lgcc'
>     ;;
> worked for static thunderbird. -lgcc is used only when finally linking the
> static exe. Not yet tested with firefox or seamonkey.

Hmm, my build setup included
   ac_add_app_options mail --disable-shared
   ac_add_app_options mail --enable-static
   ac_add_app_options mail --enable-lightning
and thunderbird.exe is 9 MB, so static worked. Even with just adding -lgcc to the cairo libs. (I convinced myself that that's where it really belongs, because we really only need it for the symbol in cairo.)

> Would we be able (from the view of license) to use -lgcc by adding it to
> OS_LIBS?

I don't think that changes anything. But that really depends on the license the the GCC lib...

Comment 27

[Peter Weilbacher]

OK, so we can definitely not statically link to GCC*.DLL. I checked that at least gcc\builtins.c and gcc\builtins.def (where the popcount stuff is defined) is under GPLv3. [Some of the .h files in gcc explicitely allow linking to non-GPL code, but the .c files do not.]

But somehow I'm a blockhead: how can I dynamically link to GCC*.DLL so that the linker finds the popcount symbol and I can at least require that users download GCC*.DLL seperately? I don't see a DLL import library in the GCC distribution, so how can some files be linked to GCC*.DLL but the linker still not find popcount?

Comment 28

[Dave Yeo]

The import library is lib/gcc/i386-pc-os2-emx/3.4.6/gcc346.a from which it is easy to create an OMF import library.
The problem is that gcc346.dll seems to not have any exports. I created a DEF from it and it is short,
;
; gcc346.def (created by emximp)
;
LIBRARY GCC346 INITINSTANCE TERMGLOBAL
DESCRIPTION 'GNU GCC Runtime Version 3.4.6'
EXPORTS

So it is broken. Simplest way to build a working DLL would be to run DLLAR.CMD on libgcc.a
Using the example at the bottom of the help, which luckily creates gcc290.dll, I get a 1143587 byte DLL plus import libraries.

Comment 29

[Walter Meinl]

(In reply to comment #27)
> 
> But somehow I'm a blockhead: how can I dynamically link to GCC*.DLL so that the
> linker finds the popcount symbol and I can at least require that users download
> GCC*.DLL seperately? I don't see a DLL import library in the GCC distribution,
> so how can some files be linked to GCC*.DLL but the linker still not find
> popcount?
To create the import libs I adapted MakeOMFlibs.cmd and executed it in /usr/local/lib/gcc (my location of gcc346.dll), then I found gcc346.lib, libgcc.lib and all the other *.lib (derived from the respective *.a files.
I cannot confirm Dave's comment about the missing symbols in the def file created from gcc346.dll (from the 20080930 build of Paul). After fiddling around how to use emximp correctly I had in my gcc346.def file all references to symbols including popcount. (Interestingly I could obtain a similar short def file like Dave from the gcc335.dll).

The trick to link against gcc346.dll was to add -lgcc346 instead of -lgcc.
Now I see SYS0002: The system cannot find the file specified. "GCC346" when I start a seamonkey built with this linker directive and gcc346 is not in the libpath. When it is in the libpath seamonkey starts. Thus, we have to find a way to append the modified version number of gcc to the -lgcc linker directive.
However, when I look in the thebes.map file created I see that thebes.dll is linked to E:\usr\local\lib\libstdc++.lib for several symbols. If desired I can attach the map file. Wouldn't be linking against libstdc++ also a problem in regard to license?

Comment 30

[Peter Weilbacher]

libstdc++ is luckily an exception to the strict (L)GPL usage, in its headers it always says:
   As a special exception, you may use this file as part of a free
   software library without restriction.
I checked this in libstdc++-v3 in the GCC-4.3.2 distribution.


For the gcc version number to be used for linking we could do something like
   # workaround for GCC >3.3.5 where builtins are missing from kLibc
   CC_VERS="$CC -v 2>&1 | awk '/^gcc version/ { print $3 }' | sed 's,\.,,g'"
   if ! test "$CC_VERS" = "335" ; then
       CAIRO_FT_LIBS="${CAIRO_FT_LIBS} -lgcc${CC_VERS}"
   fi
in configure.in. Haven't tested this, though.

Comment 31

[Dave Yeo]

GCC 3.3.5 used dllar.cmd to create gcc335.dll using a command like this, (there are a few versions in the archive all more or less the same)

SHLIB_LINK      = export DLLAR_CMDLINE="@shlib_objs@" && \
        $(REXX) dllar.cmd -o $(SHLIB_DLLNAME) \
        -ordinal @multilib_flags@ -nocrtdll \
        -flags "-Zhigh-mem -Zomf -g" \
        -ex "___main ___do_global_* ___ctordtor* ___eh* _DLL_InitTerm" \
        -d "GNU GCC Runtime Version $(gcc_version)" \
        -libf "INITINSTANCE TERMGLOBAL" -lc_alias -lc_dll  \
        && ar rs $(SHLIB_BASENAME).a libgcc/__main.o libgcc/emx-ctordtor.o libgcc/emx-eh.o \
    && emximp -o libgcc_so_d.a $(srcdir)/config/i386/emx-libgcc_so_d.def \
        && ar rs libgcc_so_d.a libgcc/__main.o libgcc/emx-ctordtor.o libgcc/emx-eh.o \


@shlib_objs@ can be replaced with gcc.a and lxlite will unpack the archive.
I've been running a build with thebes linked against gcc346.dll (built with dllar) for a week now. Only problem is that something seems to be using a lot of memory. (swap is currently 433 MBs with 30MBs free out of 512 MBs memory)
Probably simplest if Paul can fix the build system to use dllar to create the DLL. Also note that Knut was using kRx.exe to run dllar. I have a version of kRx.exe in Odin but it crashes so I used cmd.exe

Comment 32

[Dave Yeo]

Actually looking at the 3.4.6 source, gcc346.dll just get built with dllar, this includes lxliting which is probably why there are no exports.
Nowadays building with -Zomf should seamlessly link in aout type import libraries (and static libraries).

Comment 33

[Peter Weilbacher]

Attachment: part 3: use -lgcc<version>

OK, so in comment 30 I forgot the backticks, but this does produce the correct result.

Problem is that I still cannot link. I tried Firefox with GCC 4.3.2 and either it is still linking against gcc432.a and then I get this:
   emxomf: Symbol multiply defined: __GLOBAL__F___ctordtorInit
   emxomfld: a.out to omf conversion failed for 'X:\Tools\GCC432\bin\..\lib\gcc\i386-pc-os2-emx\4.3.2\gcc432.a'.

or when I move that out of the way I get
   emxomf: Input file `X:\TOOLS\GCC432\lib\gcc432.lib' is not an a.out file
   emxomfld: a.out to omf conversion failed for 'X:\TOOLS\GCC432\lib\gcc432.lib'.
so my .lib file seems to be broken. MakeOmfLibs.cmd just does something like
   emxomf -s -p128 gcc\i386-pc-os2-emx\4.3.2\gcc432.a
to produce the .lib file. But when running that I get the same message about __GLOBAL__F___ctordtorInit as above, so I guess there is a problem with gcc432.a and so I cannot produce a valid .lib file from it.

In any case, this patch should work in principle and at least for GCC 3.4.6.

Comment 34

[Peter Weilbacher]

Attachment: [checked in] part 4: the nsDragWindowProc fix

OK, this is the other fix that Paul already mentioned in his original posting about GCC 4.3.2. Instead of moving the whole function I just added the function prototype near the top of the file, together with the other prototypes. I guess it should have been there from the beginning and doesn't seem to disturb older GCCs (tested by just re-compiling in widget\src\os2 with 3.3.5).

Comment 35

[Paul Smedley]

Just a comment re: the discussion on linking against libgcc.

Included in the libgcc2.c source file is the following statement:
"In addition to the permissions in the GNU General Public License, the
Free Software Foundation gives you unlimited permission to link the
compiled version of this file into combinations with other programs,
and to distribute those combinations without any restriction coming
from the use of this file.  (The General Public License restrictions
do apply in other respects; for example, they cover modification of
the file, and distribution when not linked into a combine
executable.)"

http://gcc.gnu.org/viewcvs/tags/gcc_4_3_2_release/gcc/libgcc2.c?revision=139673&view=markup

I guess this means we don't need to rely on the dll version of libgcc ?

Comment 36

[Andy Willis (abwillis)]

The clear intent of the wording is that it can be linked into a program (e.g. Mozilla) such that no concern regarding differences in licenses would restrict it.  Essentially, it protects the file in the sense that modification to the code must follow the GPL but may be used (linked) unmodified in a way similar to Public Domain software can be.

Comment 37

[Peter Weilbacher]

(In reply to comment #35)
> Just a comment re: the discussion on linking against libgcc.
[...snip...]
> I guess this means we don't need to rely on the dll version of libgcc ?

Ah, so that is the only source file that is involved when linking with -lgcc? Then yes, we are OK. I was always looking into builtins.c and others and those don't have this exception.

Comment 38

[Walter Meinl]

(In reply to comment #37)
> (In reply to comment #35)
> > Just a comment re: the discussion on linking against libgcc.
> [...snip...]
> > I guess this means we don't need to rely on the dll version of libgcc ?
> Ah, so that is the only source file that is involved when linking with -lgcc?
> Then yes, we are OK. I was always looking into builtins.c and others and those
> don't have this exception.

Moreover, we do also link against gcc322.lib or libgcc_so_d.lib when building with gcc332 or gcc335, respectively, as I found out when I grepped through old build trees for 'gcc332' or 'libgcc'. All exe and dll files and the respective map files show up as hits. The object files linked in are those described in comment #31.
That brings me to the question why we need to explicitely specify -lgcc. Googling for -lgcc showed discussions, where it was said that all symbols defined in libgcc should be found and resolved during build by the compiler.

Comment 39

[Peter Weilbacher]

Attachment: part 3: use -lgcc

OK, so then this is really what we can and want to do. (Then I don't see a need to exclude GCC 3.3.5, either.)

Comment 40

[Peter Weilbacher]

Comment on attachment 344762 [details] [diff] [review]
part 3: use -lgcc

Oops, didn't see Walter's comment before posting that. So this may be something to be fixed in the newer compiler versions.

Canceling r? for now.

Comment 41

[Walter Meinl]

Comment on attachment 344591 [details] [diff] [review]
[checked in] part 4: the nsDragWindowProc fix

the patch works with gcc-3.4.6 as well as 4.3.2 (20081025)

Comment 42

[Peter Weilbacher]

Comment on attachment 344591 [details] [diff] [review]
[checked in] part 4: the nsDragWindowProc fix

http://hg.mozilla.org/mozilla-central/rev/cca374ab1d32

Comment 43

[Walter Meinl]

(In reply to comment #40)
> (From update of attachment 344762 [details] [diff] [review])
> Oops, didn't see Walter's comment before posting that. So this may be something
> to be fixed in the newer compiler versions.
> 
> Canceling r? for now.

(In reply to comment #38)
> (In reply to comment #37)

> Moreover, we do also link against gcc322.lib or libgcc_so_d.lib when building
> with gcc332 or gcc335, respectively, as I found out when I grepped through old
> build trees for 'gcc332' or 'libgcc'. All exe and dll files and the respective
> map files show up as hits. The object files linked in are those described in
> comment #31.
> That brings me to the question why we need to explicitely specify -lgcc.
> Googling for -lgcc showed discussions, where it was said that all symbols
> defined in libgcc should be found and resolved during build by the compiler.
Ok, I think I got it: gcc355 automagically links not agains libgcc but against libgcc_so_d.lib (no matter it would also link against libgcc_so.d.a by creating a temporary .lib file).
In gcc346 or 432 the difference between the static libgcc.a (pulled by -lgcc) and gcc346.a (pulled by the supposed -lgcc(version)) is that the archive libraries contain the _popcount symbols while libgcc_so_d.{a,lib} _does not_. For testing this, I renamed gcc346.a to libgcc_so_d.a and was able to build seamonkey without the -lgcc trick in configure.
Actually looking at Paul's patches I saw that gcc/config/i386/emx-libgcc_so_d.def is used when libgcc_so_d.a is built and the file is used unchanged from the gcc335 build tree. Thus, it misses symbols like popcountsi introduced in later compiler versions. Consequently these symbols are not contained in libgcc_so_d.a but as they are built using there own def files they are present in libgcc.a and gcc(version).a. When you look at libgcc_so_d.def it was updated for gcc335. However, this file is an awk created file extracted from trunk/libc/src/libc/libc.def (libc build tree). Thus, I'm not sure how to deal with it, building also a new libc with a new libc.def file?
A hint which symbols were added in newer gcc versions comes from the gcc source tree in gcc/libgcc-std.ver. But which ordinals to add to the new symbols?
Probably, a discussion for the netlabs.libc user group

Comment 44

[Walter Meinl]

I could also build a static thunderbird without adding -lgcc to configure when I did the renaming of gcc346.a to libgcc_so_d.a.

However, gcc346.dll has to be in a directory included in the LIBPATH when linking against libgcc_so_d.{a,lib}.

Comment 45

[Peter Weilbacher]

OK, with bug 476134 fixed (at least in mozilla-central for now), are there any other issues that we need to address before closing this bug?

Should we back out the fix about nsDragWindowProc. If I understood correctly, that was a bug in our 3.4.6 build and isn't required any more for Paul's newer 4.3.x releases.

Well, let me try to produce a nightly build with GCC 4.3.3.

Comment 46

[Peter Weilbacher]

Well, the nightly would be useless for normal users, because it depends on gcc433.dll. And -lgcc doesn't even fix that any more. Now I see what KMH was talking about in the gmane.org.netlabs.libc.user...

Comment 47

[Walter Meinl]

Well, another problem is the immediate crash when loading the java plugin in a gcc-4.3.x build, but we could open a new bug about that. (And I see some SIGSEGV with XPCSHELL and MOZJS.DLL when running the xpcshell tests in the necko dir. These SIGSEVs in the tests I don't see with gcc-3.3.5 builds.)

Comment 48

[Steve Wendt]

(In reply to comment #46)
> Well, the nightly would be useless for normal users, because it depends on
> gcc433.dll. And -lgcc doesn't even fix that any more.

This doesn't seem terribly different from the current requirement for libc063 (which includes a gcc322.dll).  A libc064 release would be nice, but alternatively, a gcc433 package could be made available, right?

Comment 49

[Walter Meinl]

(In reply to comment #48)

> 
> This doesn't seem terribly different from the current requirement for libc063
> (which includes a gcc322.dll).  A libc064 release would be nice, but
> alternatively, a gcc433 package could be made available, right?

;-) midair collision wanted to suggest almost the same ;-)

Comment 50

[Peter Weilbacher]

(In reply to comment #47)
> Well, another problem is the immediate crash when loading the java plugin in a
> gcc-4.3.x build, but we could open a new bug about that. (And I see some
> SIGSEGV with XPCSHELL and MOZJS.DLL when running the xpcshell tests in the
> necko dir. These SIGSEVs in the tests I don't see with gcc-3.3.5 builds.)

Are you saying that isn't fixed by bug 476134 or have you not tried again since this afternoon?

(In reply to comment #48)
> This doesn't seem terribly different from the current requirement for libc063
> (which includes a gcc322.dll).  A libc064 release would be nice, but
> alternatively, a gcc433 package could be made available, right?

I can already see the dozens of postings in the newsgroup and elsewhere because it is asking too much of the users to read README.txt or a similar hint on a download webpage. ;-)
I would rather wait until Paul had time to fix that. It's not only a problem for us.

Comment 51

[Walter Meinl]

(In reply to comment #50)
> (In reply to comment #47)
> > Well, another problem is the immediate crash when loading the java plugin in a
> > gcc-4.3.x build, but we could open a new bug about that. (And I see some
> > SIGSEGV with XPCSHELL and MOZJS.DLL when running the xpcshell tests in the
> > necko dir. These SIGSEVs in the tests I don't see with gcc-3.3.5 builds.)
> 
> Are you saying that isn't fixed by bug 476134 or have you not tried again since
> this afternoon?
> 
To be honest I couldn't resist to apply the patch some days ago and that build did crash. I will checkout again, maybe sth else was problematic - and I also build with the nanojit enabled (bug474020) could be also a reason

Comment 52

[Walter Meinl]

(In reply to comment #47)
> And I see some
> SIGSEGV with XPCSHELL and MOZJS.DLL when running the xpcshell tests in the
> necko dir. These SIGSEVs in the tests I don't see with gcc-3.3.5 builds.)
Ah, I've written out of my mind, it's not SIGSEVs it's SIGFPEs in the test (that I see only with 4.3.3, not with 3.3.5)
E:/usr/src/hg/mozilla-central/testing/xpcshell/test_all.sh: line 113:  3470 Floating point exceptionNATIVE_TOPSRCDIR="$native_topsrcdir" TOPSRCDIR="$topsrcdir" $xpcshell -j -s $headfiles -f $t $tailfiles 2>$t.log 1>&2
TEST-UNEXPECTED-FAIL | ../../../../_tests/xpcshell-simple/test_extensionmanager/unit/test_bug430120.js | test failed, see log
../../../../_tests/xpcshell-simple/test_extensionmanager/unit/test_bug430120.js.log:
>>>>>>>
*** test pending
*** test pending
*** Blocklist::_loadBlocklistFromFile: blocklist is disabled

Killed by SIGFPE
pid=0x0d8f ppid=0x0d8e tid=0x0001 slot=0x00b9 pri=0x0200 mc=0x0001
E:\MOZBUILD\DIST\BIN\XPCSHELL.EXE
MOZJS 0:00004167
cs:eip=005b:1cf04167      ss:esp=0053:0011ccb4      ebp=0011ccdc
 ds=0053      es=0053      fs=150b      gs=0000     efl=00010206
eax=41e00f62 ebx=201774a0 ecx=201522a0 edx=0011cd0c edi=0011cd1c esi=0011cd14
Process dumping was disabled, use DUMPPROC / PROCDUMP to enable it.

<<<<<<<
I see similar errors in a few other tests, while most tests pass ok or have the same error as with gcc-3.3.5.
IIRC, there was some particular floating point code in js somewhere for OS/2.

Comment 53

[Andy Willis (abwillis)]

I see references to the fact that Java is not working with 4.3.x builds but I don't see mentioned the fact that if ipluginw.dll is brought over from a 3.3.5 build that Java does work in 4.3.x builds (at least it is in this 4.3.3 build).

Comment 54

[Walter Meinl]

(In reply to comment #53)
> I see references to the fact that Java is not working with 4.3.x builds but I
> don't see mentioned the fact that if ipluginw.dll is brought over from a 3.3.5
> build that Java does work in 4.3.x builds (at least it is in this 4.3.3 build).
I can confirm, a 3.4.6 built ipluginw.dll doesn't crash as well. I built a debug enabled Minefield with gcc-4.3.3, that crashed also as expected when the java-plugin was loaded, from the log:
For application/x-java-vm found plugin D:\PROGRAMS\MOZ_PLUG\npj2.dll
ipluginw: nsInnoTekPluginWrapper::CreatePlugin: enter
ipluginw: nsresult npXPCOMGenericGetFactory(nsIServiceManagerObsolete*, const nsIID&, const char*, const char*, PRLibrary*, nsIPlugin**): enter
ipluginw: nsresult npXPCOMGenericGetFactory(nsIServiceManagerObsolete*, const nsIID&, const char*, const char*, PRLibrary*, nsIPlugin**): aClassName=<NULL>
ipluginw: nsresult npXPCOMGenericGetFactory(nsIServiceManagerObsolete*, const nsIID&, const char*, const char*, PRLibrary*, nsIPlugin**): aClass={ffc63200,cf09,11d2,a5,a0,bc,8f,7a,d2,1d,fc} <unknown> (0x141cb460)
ipluginw: nsresult npXPCOMGenericGetFactory(nsIServiceManagerObsolete*, const nsIID&, const char*, const char*, PRLibrary*, nsIPlugin**): aContractID=<NULL>
ipluginw: nsresult downCreateWrapper(void**, const void*, nsresult): pvvResult=139af220, pvVFT=11e320, rc=0
ipluginw: nsresult downCreateWrapper(void**, const void*, nsresult): *aDownInterfaces[iInterface].pIID={00000000,0000,0000,c0,00,00,00,00,00,00,46} NS_ISUPPORTS_IID (0x139ad090)
ipluginw: nsresult downCreateWrapper(void**, const void*, nsresult): Created wrapper 236aef80 for 20047858.
[crash]
Thus, at least the creation of the wrapper seems to work.
I then run make clean in the os2wrapper and rebuilt only ipluginw.dll with gcc-3.4.6 (3.3.5 didn't work because of an unsupported compiler option).
The output of the log is nearly the same up to the point when the 4.3.3 built ipluginw.dll crashes
Built with gcc-3.4.6 output goes on like this:
ipluginw: nsresult downQueryInterface(void*, const nsIID&, void**): enter this=0x21d79380 (down)
ipluginw: nsresult downQueryInterface(void*, const nsIID&, void**): aIID={8bb35ed9,e332,462d,91,55,4a,00,2a,b5,c9,58} NS_ISERVICEMANAGER_IID (0x22657790)
ipluginw: nsresult downQueryInterface(void*, const nsIID&, void**): Supported interface. Calling the real QueryInterface...
[snip]
So, the 4.3.3 built ipluginw.dll seems to crash when doing the function downQueryInterface
from the source wrap_XPCOM.cpp line 5555
nsresult VFTCALL downQueryInterface(void *pvThis, REFNSIID aIID, void** aInstancePtr)

I'm wondering if the crash has sth to do with VFTCALL, which is defined as _Optlink in wrap_VFTs.h.
There is quite some difference in the patches Paul used for gcc-3.4.6 and 4.3.x with regard to optlink in gcc/config/i386/i386.c where most of this stuff is contained.
Well, if I understood it correctly those java plugins need the _Optlink calling convention.

Comment 55

[Paul Smedley]

Yeah - Optlink support basically doesn't exist in 4.3.x - the amount of changes in i386.c between 3.4.6 and 4.3.x made it very hard to apply the diffs.

I'll try and revisit this during this coming work as I'm on leave.

Comment 56

[Paul Smedley]

OK i played with i386.c a little, and now loading java doesn't crash, but neither does it work :( the optlink code is messy - maybe if I understood what it was trying to do it would help!

Comment 57

[Peter Weilbacher]

With ipluginw gone on trunk and the rest (mostly) building with GCC 4.4.0, is there still a reason to leave this bug open? We can do the -static-libgcc thing in setmozenv.cmd.

Comment 58

[Steve Wendt]

Maybe it makes sense to open separate bugs for any remaining issues.  For example, the IPluginW issue still applies to the branches, even if it is useless on trunk.

Comment 59

[Peter Weilbacher]

I don't think there is any point in trying to get later GCCs to fully work for 1.9.1 and 1.9.0 branches. And GCC 4.0.0-20090426 works great with mozilla-central (the remaining problem with the int types in nsCanvasRenderingContext2D.cpp is apparently a compiler problem and not caused by the Mozilla code).

So I'm calling this fixed.

Comment 60

[Peter Weilbacher]

Comment on attachment 344762 [details] [diff] [review]
part 3: use -lgcc

Instead of this, -static-libgcc should be added to the GCCOPT environment variable. I have added a new CMD file for GCC 4.4.0 on https://developer.mozilla.org/index.php?title=En/Developer_Guide/Build_Instructions/OS%2F%2F2_Build_Prerequisites/Building_on_OS%2F%2F2_using_Mercurial which does that.

Comment 61

[Walter Meinl]

Just a short HOWTO for those who want to compile SeaMonkey or Firefox-3.5.x with gcc-4.3.3 or 4.4 (other gcc's than 3.3.5 should be used on own risk;) and want to have a working ipluginw.dll:
Let the compile with gcc-4 finish. Open another cmd or 4os2 session and start setmozenv for gcc-3.3.5, go to the objdir, edit (mozilla/)config/autoconf.mk for Firefox or SeaMonkey (the right one is in mozilla/config/autoconf.mk). Find the line "OS_CXXFLAGS" and remove  "-Wno-invalid-offsetof" from that line. It's an option gcc-3.3.5 doesn't know about and will error out because of that. Then simply "make -C (mozilla)/modules/plugins/os2wrapper clean" and rebuild ipluginw.dll with gcc-3.3.5 by "make -C (mozilla)/modules/plugin/os2wrapper". Be happy ;-)