--- Mumit Khan <khan@...> wrote: > On Tue, 19 Jun 2001,
Paul Moore wrote:
> > I know it depends on lots of things (not least how many people
> help!) but is
> > there any estimate of when a mingw port will exist? I ask mainly
> because I
> > have *no idea* how hard a task this is, so I don't know whether to
> think in
> > terms of weeks, months, or years...
> I looked at it a few days ago, and here're a few issues that need to
> 1. Mingw runtime -- some of the headers need to be "fixed", mostly so
> GCC can be built easily without having to move GCC headers out of the
> as I used to do eons ago. The list includes stdarg.h, varargs.h,
> and perhaps limits.h (this may be fine). This is quite simple, but is
> going to take a bit of careful work -- mainly merging in the common
> includes without breaking anything else. Some of the items from
> needs to be copied into math.h (with guards) for libstdc++ math
> These changes can be quite clean if done right. I need to write up
> the various changes that I *think* are/may-be needed, and go from
> 2. GCC build issues:
> a. I'm having severe problems with relocatable packaging (this is the
> so called "relative pathname" patch applied to mingw releases since
> olden days). Don't know what's changed, but this one needs to be
> for the package to be usable without a lot of error-prone twiddling.
> b. Canadian cross is giving me a bit of trouble, but that may just be
> to my absense in playing with GCC on a regular basis. [ I build a
> hosted mingw targeted toolchain, which is the cross part; then I
> build the
> native toolchain on a Linux box using the cross compiler, which is
> Canadian cross part ]
> 3. libstdc++-v3 issues:
> a. Have to patch the configury a bit to not use newlib ctype by
Why not the safe_ctype now in libiberty?
> b. The numeric limits may not be correct as built, needs checking.
> c. There may be issues with some of the headers that shadow/wrap C
> but those will fall out as folks try out building various packages.
> 4. Java? ObjC? Don't know what the status is since I didn't try to
> those front-ends.
> Most of the patches that Mingw releases contain are in the v3 tree,
> for these two:
> 1. fnative-struct -- needed for maximal interopability with native
> by using the same bit field layout, which is somewhat different from
> other platform's.
> gcc-2.95.2-msvc-bitfield-pack.diff .. Donn Terry's MSVC compat
> layout/pack patch.
> gcc-2.95.2-winnt.diff ............... Hack to support entire classes
> DLLs in C++.
> I haven't looked at Mingw gcc sources lately to see if these have
> improved on since.
Mumit--perhaps you could assign some of this to others here. I would
feel comfortable with porting Donn Terry's stuff. As far as C++ DLL
support, I have submitted one change - viz: don't use context to mark
initialised static const data members as dllimport - which is in cygwin
and mingw sources now.
> The only local changes I've made are:
> 1. Make MSVC the default; to get CRTDLL, you'll have to configure as
> 2. Some configury changes to libstdc++.
> 3. A small change gthr-win32.h to work with libstdc++.
> 4. Change to gen-num-limits.cc to not use SIGTRAP.
> I'll have to rebuild everything from scratch and pay a bit more
> to the problems that I run into, but overall it was rather easy if
> already know how to do the usual native->cross->canadian_cross etc.
> Without having native building capability anymore, I have to first
> find a
> solution to the relative pathname issue before I go further.
> Currently I
> can use it, but only after carefully crafting C_INCLUDE_PATH, etc
> variables, but that's annoying even in the test phase.
Please, if you need any help testing your patches on native builds, I
can test on NT.
http://messenger.yahoo.com.au - Yahoo! Messenger
- Voice chat, mail alerts, stock quotes and favourite news and lots more!