ITA: gcc-mingw-* gcc-3 -mno-cygwin support packages; ITP: mingw-binutils/mingw-gcc-* cross compiler
Wed Jan 12 04:23:00 GMT 2011
On 1/11/2011 8:12 PM, Yaakov (Cygwin/X) wrote:
> On Tue, 2010-11-23 at 17:28 -0500, Charles Wilson wrote:
>> ------------------ 1 ---------------
>> The first set of packages are revisions (actually, just rearranging the
>> contents) of the venerable add-on packages that provide -mno-cygwin
>> support for gcc-3.
> Why can't we keep things simple and just dump those outright? Aside
> from nostalgia, what reason do we have to continue supporting gcc3 when
> AFAIK no other major distro does so?
> This would mean making these empty _obsolete packages (with cleanup
> postinstall scripts if necessary), and dropping the gcc-mingw-* deps
> from gcc-* (3.x).
There are two reasons. First, if something goes belly up with the new
cross compiler (but not the headers and runtime libs) I want a fallback
for folks. And, "rolling back" is going to be difficult, given (again)
the weird directory/symlink manipulations that the existing
(rolled-back-to?) gcc-mingw "add-on" packages perform.
Second -- and related -- given the weird things that the *current*
gcc-mingw "add-ons" do to the file system, and the need to "undo" it in
an orderly fashion so that the "real" mingw cross files can be
installed...I think I need to release the updated gcc-mingw "add-on"
packages first, for about a month BEFORE releasing the actual gcc4-based
mingw cross compiler [*] (whatever the actual contents of these "add-on"
packages might be: actual files, or empty except for a cleanup
If these updated gcc-mingw add-on packages were simply empty _obsolete
packages (with the cleanup postinstall script, as needed by the "future"
real mingw cross packages), then...the result would be I'd break
people's working gcc3 -mno-cygwin setup, WITHOUT immediately providing a
I don't think that's acceptable.
[*] See below for why I think this month-long "waiting period" is necessary.
>> ------------------ 3 ---------------
>> The third group of packages is the actual cross compiler toolchain. This
>> = mingw-binutils-2.20.51-1-src.tar.bz2
>> = mingw-binutils-2.20.51-1.tar.bz2
>> = mingw-gcc-4.5.1-1-src.tar.bz2
>> = mingw-gcc-core-4.5.1-1.tar.bz2
>> = mingw-gcc-fortran-4.5.1-1.tar.bz2
>> = mingw-gcc-g++-4.5.1-1.tar.bz2
>> = mingw-gcc-objc-4.5.1-1.tar.bz2
> Of course, by now binutils 2.21 and gcc-4.5.2 are out...
Ack. Assuming we can move forward, I'll update as required. Oddly,
running strings on i686-pc-mingw32-ld.exe and grepping for the search
dir macro, I get:
SEARCH_DIR("=/usr/local/lib"); SEARCH_DIR("=/lib"); SEARCH_DIR("=/usr/lib");
which means that cross ld will search, by default and in the absence of
better path information from the $lang driver, in $sysroot/lib/,
$sysroot/usr/local/lib, and $sysroot/usr/lib -- NOT in
$sysroot/mingw/lib. Now, this doesn't REALLY matter if you always use
the i686-pc-mingw32-$lang driver to link, but it seems odd.
Should I fix this?
> BTW, do these include the shrext=.dll.a patch for config.rpath? This is
> necessary for dynamic linking against libintl in binutils, gcc, and gdb.
Yes, I'm explicitly patching config.rpath for mingw-gcc and mingw-binutils.
>> These tools are configure as cross-compilers with sysroot support -- the
>> gcc configuration CYGCONF_ARGS are:
> I presume that these match the "official" native MinGW options, so that
> binaries are compatible?
Well, now, that's an interesting question. That is, of course, the
GOAL, but here's how mingw.org's gcc-4.5.0 (they don't have a 4.5.1 or
4.5.2 yet) is compiled:
This presents the following ABI-changing differences:
I don't think the LTO difference is germane, but the
fully-dynamic-string part IS.
I WAS of the opinion that mingw.org's omission of that flag is a
mistake, since without it or a some patch, PR24196 leads to a crash when
passing std::strings across the DLL boundary (when the string happens to
However, after going back to the PR, it looks like Dave K. reports, as
of 2010-03, that it is fixed if you use the shared libstdc++. And, of
course, if you build your entire application using static libraries and
the static gcc/g++ runtime libs, then you never saw the problem anyway.
The only remaining danger, is if you build a C++ app with shared
libstdc++, but link to a C++ dll that itself was build using static
libstdc++. (or vice versa). I'm not too fussed about this corner case.
So, I should probably rebuild i686-pc-mingw-gcc withOUT
--enable-fully-dynamic-string (which means rebuilding all the other
mingwish lib packages). No problem.
>> When MinGW.org offers a 4.5.x compiler with java support, I'll update
>> this cross compiler to do so as well.
> FYI, I have found an issue building ecjx (which installs as ecj1) as
> part of a cross-gcc; ecjx.o is cross-compiled with xgcc instead of
> native-compiled with $host-gcc, but linked with the latter. Preliminary
> patch attached.
>> With these new packages installed, I was able to build setup.exe from
>> current CVS without issue -- by default, the existing bootstrap.sh
>> script now uses the cross compiler automatically if
>> is installed.
> I took care of mingw-gcc-4.5 issues when I discovered them as part of
> the cygport cross-compiler support development.
>> With only the gcc-mingw- "add ons" for gcc-3 installed (plus its
>> pre-requisites: mingw-binutils, mingw-w32api, mingw-runtime, AND
>> mingw-gcc-core which provides i686-pc-mingw32-gcc but NOT
>> i686-pc-mingw32-g++), I was able to build setup.exe using gcc-3
>> -mno-cygwin -- but I had to pass
>> as commandline arguments to bootstrap.sh. The attached patch does this
> Yuck. Let's just drop support for gcc -mno-cygwin and be done with it.
If you mean, dropping support within setup.exe's source repository for
building with gcc3 -mno-cygwin, fine. If you mean dropping support for
gcc -mno-cygwin *entirely* I don't think we can do that QUITE yet, for
the reasons explained above.
I'd love to do so in, say, T+6months...
>> Finally: official rollout.
>> I don't know how we can ease the pain of the three step (or, at minimum,
>> two step) install process, given the wacky things the EXISTING
>> gcc-mingw- packages have already done to the file system tree. One
>> possibility is to ONLY release the updated gcc-mingw- addons (with
>> judicious modifications of their requires: lines) and let people install
>> those. Say, for about a month.
>> Then, after the month has passed, go ahead and move the other packages
>> over to sourceware. People who "blindly upgrade" after than will bork
>> their system (it's fixable, but awkward) -- but MOST people will have
>> already upgraded their gcc-mingw (and probably didn't even notice), so
>> they'll be fine.
> I suppose the alternative is to document the upgrade steps in the
> announcement, and deal with the problems from all those that don't read
Right...the problem is, if we deploy ALL of the updated packages
SIMULTANEOUSLY, we can't guarantee the installation order (and worse,
all of the packages will be *unpacked* /before/ ANY of the post-install
scripts are run. Which means...bang, you're dead.)
So...the upgrade steps would be: "DON'T UPGRADE!!! Fix these symlinks
first, THEN run setup."
*Nobody* is going to do that. *Everybody* is going to run setup.exe
FIRST, scrog their install, and then come whining to the list.
Hence, the separate deployment plan, with a 1-month delay between phases
to allow everybody to "automatically" get their symlink stuff "fixed"
first, THEN install the other packages afterwards. The desperate (or
setup.exe maintainers!) will be able to get the delayed packages
directly from cygutils.fruitbat.org in the meantime.
More information about the Cygwin-apps