Maintainer searched

[Charles Wilson]

Dave Korn wrote:

>   Well I didn't finish rolling the lot over the weekend owing to reasons I'll
> explain on the talk list, but I'm saying yes anyway.  First thing I'll do will
> be reroll a 3.4.4-2 with the fix for PR-whateveritis about the C++

24196

It also fixes this specific problem on 4.1.0 (mingw; haven't tried 
cygwin but I assume it'll work in 4.1.0 on our platform too)

> strings-vs-dlls problem.  Once that's done and seems ok, I'll look at making
> an experimental package from one of the gcc 4 series.  (Anyone got any
> preferences?)

Either 4.1.[0,1] or the 4.2.0 devel branch.  The mingw guys decided to 
wait out the 4.0.x series because, as of last May, there were just too 
many issues on windows with that series.  It's an open question whether 
that is also true of 4.1.x or even 4.2.devel.

I built 4.1.0 (on mingw), c/c++/fortran, and it seemed to work okay -- 
of course, for fortran, I needed gmp and mpfr.  However, there are a few 
issues:

=====

(1) libjava is "hopelessly broken", according to Danny Smith. I have to 
concur -- I was not able to get it to build at all, so I gave up 
including the java compiler in my 4.1.0 build.  According to Danny, the 
java compiler requires a shared libjava (and shared libgcc) -- but see 
below about DLLs.  (According to Danny, it takes over 1G RAM to 
successfully turn a libjava.a into a DLL+implib ; I never even got 
libjava.a to build so I can't verify).

Note that the autoconfigury of gcc STILL does not support 
--enable-shared for cygwin or mingw, so people are still creating DLLs 
from their .a's -- a dangerous and flaky procedure at best, and it did 
NOT work for me.

=====

(2) bootstrapping ADA requires the gnat tool from the ADAcore project -- 
but that, in turn, requires the build to use Dwarf2 exceptions. 
However, switching to dwarf2 has significant consequences:

   (a) breaks backwards compatibility for exception handling -- this 
probably only affects C++ libraries currently in the cygwin 
distribution, plus any other users' private C++ stuff

   (b) dwarf2 means that any exceptions throw by functions passed as 
callbacks to the w32api will NOT be caught.  Unfortunately, this is a 
common paradigm for win32 GUI applications...

   (c) You can't have C/C++/Fortran be sjlj, while ada is dwarf2 -- at 
least not in the same build.

=====

(3) The patch by Danny Smith to allow throwing exceptions across DLL 
boundaries has NOT been ported to any 4.x series -- nor will it be. 
According to Danny, "I've finally convinced myself
that the patch is more trouble than its worth.  Libstdc++/libgcc as
dll's is how I work it in my own trre. So you are on your own."

   (a) unfortunately, when I tried to make DLLs post-build out of 
libgcc.a, libsupc++.a, and libstdc++.a, I couldn't get them to work -- 
every app I compiled died a horrible death before main() -- while they 
worked if I linked against static runtime libraries.

Supposedly, this is the "correct" procedure, at least until the 
autotoolization of the libgcc/libsupc++/libstdc++/libgfortran/etc is 
upgraded to support shared-lib-building on cygwin/mingw:  AFTER 
completing the static build,

   dlltool --output.def libstdc++.def --export-all libstdc++.a
   gcc -shared -o libstdc++.dll -Wl,--out-implib,libstdc++.dll.a \
     libstdc++.def libstdc++.a

(Actually, I have a slightly more complicated recipe that uses version 
numbers and also munges the .la files appropriately, I'll send that 
later).  Not that it actually gave me a working build, mind you, but...

   (b) there was a reported issue with exporting vtables and type_info 
with the shared libgcc/libstdc++/libsupc++ DLLs that, according to 
Danny, "has not yet been worked out".

Not being able to catch an exception thrown from a DLL is a huge 
restriction.  It *must* be fixed before a 4.x C++ compiler is released 
-- and there are two options:
   (1) forward port Danny's old patch -- against his wishes, or
   (2) get @#^@@#$ shared libgcc/libsupc++/libstdc++ to work
Neither is trivial.

=====

There are a number of patches to the "our" 3.4.x packages that are 
cygwin-specific but have never made it "in" to the 4.x CVS.  I don't 
know what they are, but here's a for instance:
    class declspec(dllimport) MyForwardDeclaration;
is necessary if you want to import MyForwardDeclaration from a DLL using 
the MSVC++ compiler.  On gcc, however, you don't need to include the 
declspec on forward declarations -- only at the point of actual definition:
    class declspec(dllimport) MyActualDefinition
    {
       ....
    }
If you put an attribute marker like declspec(dllimport) in a forward 
declaration, by default gcc (3.4.x unpatched, 4.x) generates a warning 
like "attribute valid only at point of definition; attribute ignored". 
Because MSVC++ needs it in both places, compiler-neutral code for 
windows tends to includes the declspec at forward declearations, and 
cygming-special-gcc-3.4.x has a patch to suppress the warning.  That 
patch needs to be forward-ported to 4.x even tho, as a platform-specific 
hack, it'll never go in to gcc CVS.

Are there others like this? I don't know.  I'm still finding them.

=====

Aside from bringing forward "missing" bits from cygming-3.4.x, there are 
also serious failures in 4.x on windows, period -- especially in 
libjava.  Danny's right: it's horribly broken, even when you're just 
trying to built static.

=====

Danny "plays" in a 4.2.0 branch (and has apparently abandoned any effort 
to get a working 4.1.x OR 4.0.x build).  However, he has said that it 
(his modified version of 4.2.x) is just a toy and not production-ready 
-- "look what it does on the hairpins", but "[it] does crash a lot".

Almost every platform is jumping off the sjlj ship -- which means that 
very little testing is happening in the guts of gcc for sjlj handling. 
It'd be nice for us to switch to DWARF2 if we could: it's MUCH faster 
and that reportedly makes a huge difference in the compiled java code -- 
to the degree that it appears that libjava+sjlj is "downright unusable 
and practically unsupported".

However, this breaks the ability on windows to do w32api callbacks, and 
there are backwards compatibility issues.  With sjlj, tho, ada is 
supposedly non-compilable; ditto java(?).  So either way you eventually 
go, your packages will have a regression from 3.4.x:
   (1) either you drop ada and java support, and we live with the 
ever-increasing brokenness that will accumulate in the sjlj code, or
   (2) you switch to dwarf2, we keep ada and java, but loose the 
callback stuff and break backward compatibility.
   (3) you release TWO entire SETS of compilers: an sjlj one with only 
C/C++/Fortran, and a "real" one with DWARF2 and the full compiler suite. 
  This is a support nightmare; I recommend against.


In short, getting a working 4.x compiler won't happen overnight, and 
requires some rather far-reaching decisions, some bugfixes and 
mailing-list haunting, and some actual coding.  I don't think there's 
any *hurry* for a 4.x compiler; as long as somebody is actually working, 
however slowly, to make it happen *eventually* would be great -- and 
more than is happening at present on EITHER cygwin or mingw.  AND, I 
reckon folks would be eager to help test, at least.

I don't mean to be discouraging, but I wanted to publicize what *I* had 
discovered, during my investigations of the 4.x issue over on the 
"mingw" side of the fence.

--
Chuck

P.S. attached find my *collected* patches for gcc-4.1 (I didn't write 
any of them, I merely collected them from various mailing lists -- and 
it doesn't include the aforementioned warning-suppress patch).  Also, 
see my "build recipe" **on mingw**, not cygwin.

WARNING WARNING WARNING:

The build recipe and patch below gave me a reasonably-working 
C/C++/Fortran compiler on mingw -- at least, until I dllized the runtime 
libraries.  Then it broke horribly.  And even the static version had 
this known problem: exceptions thrown from user DLLs would NOT be caught 
by the user application.

Use at your own risk.  no support.  etc etc etc.

WARNING WARNING WARNING
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: gcc-4.1-cwilson-collected-patches
URL: <http://cygwin.com/pipermail/cygwin-apps/attachments/20060508/0a5a0876/attachment.ksh>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: gcc-4.1-cwilson-mingw-build-recipe
URL: <http://cygwin.com/pipermail/cygwin-apps/attachments/20060508/0a5a0876/attachment-0001.ksh>