GCJ, libgcc, collect2 and MinGW

[Ranjit Mathew <rmathew at gmail dot com>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hello,

  First off, does any one know why we explicitly include libgcc's
spec in the libgcj.spec? The GCC driver already seems to arrange
for a "%G %L %G" linking sequence, where %G is the libgcc linking
spec and %L is the GCJ linking spec. Since libgcj.spec includes
libgcc's spec, we end up specifying libgcc's libraries *three
times* to a collect2 invocation. Nothing catastrophic as such,
but still weird.

On to the main query: Does anyone know the incantation that
can be used in libgcj.spec to insert in an option that will
affect even the libgcc spec that appears *before it* in the
linking sequence? For example, "gcc/config/i386/mingw32.h"
defines:
- ---------------------------- 8< ----------------------------
#define LIBGCC_SPEC \
  "%{mthreads:-lmingwthrd} -lmingw32 -lgcc -lmoldname \
    -lmingwex -lmsvcrt"
- ---------------------------- 8< ----------------------------

That is, if "-mthreads" is specified on the command line, the
"mingwthrd" library gets included before the "mingw32" library.

This is important since "mingwthrd" defines a __mingwthr_key_dtor()
function that does the proper thing for EH in a multi-threaded
environment and "mingw32" defines a dummy version for single-threaded
environments. If "mingwthrd" doesn't come first, we end up picking
the single-threaded version, which is wrong for Java and leads
to race conditions where exceptions thrown in one thread ends up
being caught in another thread.

So I need to be able to put in something for THREADSPEC when
- --enable-threads=win32 is specified that will make sure that
even the libgcc spec that comes before libgcj's spec is coaxed
into picking up "mingwthrd" before "mingw32". Hence this query.

Thanks,
Ranjit.

PS: The thread-safe version of __mingwthr_key_dtor() depends
on DLL attach-detach notifications from Windows to clean up
EH contexts and therefore makes the compiled programme depend
on mingwm10.dll.

The dummy version for single-threaded applications avoids this
dependency. GCJ has a fake definition that fools the MinGW
runtime into thinking that it is a multi-threaded environment,
but leaks 24 bytes of EH context per thread:

  http://gcc.gnu.org/ml/java/2003-04/msg00046.html

This technique has "worked" all this while, except that it is
now creating linker errors for multiple definitions of _CRT_MT
and __mingwthr_key_dtor while linking in gappletviewer, etc.

- --
Ranjit Mathew       Email: rmathew AT gmail DOT com

Bangalore, INDIA.     Web: http://rmathew.com/




-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFEqJDNYb1hx2wRS48RAtAyAJ9QJxnGA/IQ4dhBW819WQtel6i46gCfUsT2
mGYyREWWaBJlauisEd9Cfu4=
=ksZ0
-----END PGP SIGNATURE-----