Re: [MinGW-dvlpr] 3.3 patches

[Danny S. <dan...@cl...>]

----- Original Message -----
From: "Ranjit Mathew" <rm...@ho...>
To: <min...@li...>
Sent: Friday, 23 May 2003 08:32
Subject: Re: [MinGW-dvlpr] 3.3 patches


> >I've been neglecting 3.3 for awhile, because I think I've finally got
a
> >handle on the dllimport
> >fuss in winnt.c, so I've been concentrating on working up patches and
> >testsuite case for trunk.
> >
> >Do you think we should upload test release binaries now (Monday is
> >earliest for me to do), to shake out unseen bugs exposed by user
code?
>
> IMHO, yes, if you are planning to put in your dllimport changes as
well.
> After the pseudo-relocs patch in the current binutils, this would be
the
> most important thing in 3.3 w.r.t. creating and using C++ (and Java)
> DLLs.
>
Oh, I'll think I'll compromise a bit with the dllimport stuff and leave
out some bits which look safe in simple testcases but...

> Or do you want to postpone it for 3.3.1 when other changes/bug-fixes
from
> "real world use" of GCC 3.3 also make it into the FSF sources?

My experience with 3.0 and 3.1 (and 3.2 which is really 3.1)  is that
the first round of bug fixes is quite significant.  I actually would
prefer to wait to 3.3.1 since I have a heeeap on at the moment and
starting to feel the stress and then I make silly mistakes
>
> BTW, how do we plan to release this? Something like "core" (C/C++)
plus
> "language packs" (Ada, ObjC, Fortran, Java)?
>
I probable would keep ObjC and Fortran with core, since they are
relatively small additions.  So three packages.

> The last time (3.2), I had "diff"-ed files from MinGW GCC 3.2 and my
own
> build to get the "gcj3.2" files. This worked seamlessly since the core
> GCC driver automagically knew how to invoke the Java front-end when
> "gcj3.2" files were unarchived into the same location.
>
> In 3.3, the front-ends have been separated in a much cleaner way but
> that has also confused me - would the core driver know how to invoke
> the Java front-end if you (Danny) don't compile with "java" in your
> "--enable-languages"?
>
> The "default_compilers" array in "gcc/gcc.c" would seem to imply that
> this is not an issue, but "gcc/java/lang-specs.h" and the
"gcc/configure.in"
> script's handling of "--enable-languages" muddle this up (for me).
>
> So Danny, do you plan to build all the front-ends (and libraries)
together
> in one jumbo build?

Yes.  Even if I am not the person uploading the java frontends and libs,
at least the gcc driver will be built the same way as yours.

(If you take the patches I linked to in the previous
> message, this should be painless, except for the extra build time.)

Building is relatively painless.  I just go away and kick some sheep for
awhile (just kidding,  I talk nicely to sheep--"grow, you stupid
buggers, grow"--I kick the dog instead)  Uploading to sourceforge is
painful because it costs me money.
>
> Or do you want us (Mohan and I) to separately build the "gcj3.3" files
> and upload "diff"-ed files as in 3.2? Will it work as well as in 3.2
then?
>
You two would be more aware of any packaging mishaps than I would.
Don't know how it will work until we try.  But as I said I'm short of
time.  As I reread this message, I realize that I haven't been very
definite about anything.  Maybe after a couple nights sleep I'll be
right.

Danny
> Ranjit.
>
> _________________________________________________________________
> Go where the action is. Get MTV Citibank card.
> http://server1.msn.co.in/msnleads/citibankcards/mtv.asp It's cool!
>
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: ObjectStore.
> If flattening out C++ or Java code to make your application fit in a
> relational database is painful, don't do it! Check out ObjectStore.
> Now part of Progress Software. http://www.objectstore.net/sourceforge
> _______________________________________________
> MinGW-dvlpr mailing list
> Min...@li...
> https://lists.sourceforge.net/lists/listinfo/mingw-dvlpr