Danny Smith wrote:
> ----- Original Message -----
> From: "Aaron W. LaFramboise" | I'd like to see the following list of
> features (and perhaps some more I
> | don't remember at the moment) implemented or working with the official
> | FSF GCC and binutils, and the MinGW runtime, by the end of GCC 3.5's
> | stage 2, which will probably be about September 1.
>
> You.re dreaming. September 2005 might be realistic.
I suppose we'll see. :)
> | Shared libgcc, libstdc++, and libsupc++
>
> Licensing issues and versioning are the bugaboo's here. The dll's are
> fairly easy to build now, but with some gotchas using auto-import. If
> some of the work that Mark Mitchell has hinted at is incorporated, this
> will b easier to progress.
Well, what exactly is the licensing issue? As near as I can tell, all
of libstdc++-v3, libsupc++, and libgcc2 are GPL with library exception,
which as near as I can tell means users of GCC have no particular
obligations at all with regards to dynamic versions of these three
libraries when they are distributed in binary form. I am wrong?
One reason I'd like dynamic libraries to work (besides the obvious
reason that its something other targets support) is to allow DLLs linked
under diverse differing GCC version conditions to work, as it does on
Linux. I don't think this will ever work very well without the dynamic
libraries.
Outside of licensing issues, I think it would be valuable to be able to
support correct behavior both with and without dynamically linked GCC
libraries.
Can you give me a pointer to this work of Mark Mitchell?
> | Stabilized multithreading support
>
> I think we should get rid of _all_ the inline stuff in gthr-win32.h. At
> least that would settle the interface for now.
What is the story on that gthr multithreading stuff discussd on the list
a while ago? In my humble opinion, it will be very difficult to ever
top that implementation (outside of possible bugs or new incompatible
Windows versions), and I do not think it would need to be changed for
quite a while. I think getting it committed to the FSF tree should be a
priority.
As far as inlining goes, I have no particular opinion. Inline or no, if
the implementation changes again, its almost certainly going to be an
ABI difference. I do think, however, that correct inlining could speed
up that particular locking algorithm dramatically in some situations. I
haven't seen what is being considered as the final patch, so I can't
discuss this in detail.
> | Completed C99 support in mingwrt
> |
> I have the mbrtowc etc family sitting on my hard disk for about 18
> months now. Can you help with testing (locale locking in MT apps).
Absolutely. E-mail it, upload it to a webpage, or commit to CVS,
whatever, and I'll put it in the queue.
> | Correct C++ <cxxx> header support
>
> There is a CVS branch of mingw runtime that supports correct C header
> namespace issues. It is bitrotten now, and I've even forgotten what its
> called. This was a hobby horse of mine for awhile, and I would love to
> spend more time on it.
>
> | Library symbol-correctness
>
> Explain please.
This is related to the previous two items.
I want two features that I do not beleive are presently garenteed:
1) When gcc -std=c89 or -std=c99, or g++ -std=c++98, is specified, I
want to have all names the standard garentees to be accessable. I also
do not want anything else, barring reserved names, that might make a
conforming program not work. I would like extension headers, such as
what MSVC provides, to have similarly conformant semantics.
2) I want some sort of 'strict' option or macro that will disable all
direct access to extension identifiers, such as _open. I'd also like to
still have some way to access these functions through an uglified prefix.
Also, I think as many mingwrt-specific identifiers as reasonable should
be moved to a __mingwrt_ or similar prefix. While mingwrt is considered
an implementor, it would be nice if compatibility with odd situations
could be preserved as much as possible.
I have some small peices of code that can be used to test that these
requirements are met.
> | Win32 locale support, Win32 libiconv
>
> See above (and below re nl_lang interface). Libiconv build OOB and
> there is even an official w32 binary available from project maintainers.
> Again there are licensing issues. I like the GPL but I'm afraid that
> many mingw users will not respect the licensing requirememts.
What I meant is that I think GNU libiconv should be unnecessary.
I have simple code for a POSIX iconv.3 interface that uses the Windows
API, similar to what you mentioned below. I'd like to make this into a
form that it could be included into something somewhere in the Windows
GNU toolchain.
I also want libstdc++-v3's locale support to work as well as Windows as
it does on GNU.
> The libiconv issue has an immediate relevance to libgcj.a and its
> support of charsets.
I don't know anything about this. Does this mean that libgcj.a has a
particular dependence on GNU libiconv, or would any iconv be acceptable?
> | libmudflap
> |
> Ouch. There is so much Posix-ism in libmudflap, that this will be a
> hard one, especially with sockets
To be honest, this is primarily wishful thinking, and this will be the
last thing I work on. I do feel it is valuable, though.
> | Any other major missing features other ports have that MinGW doesn't
> | that I missed?
>
> Dwarf2 EH support that works with win32api callbacks as well as CRT
> signals
Yes, I forgot about EH. I've been meaning to experiment with a few
ideas of mine for a while now. Are there any proposed solutions or
implementations for MD_FALLBACK_ whatever-it-is or anything like that
yet? Is anyone actively working on this?
Aaron W. LaFramboise
|
