On Tue, 2011-01-11 at 23:23 -0500, Charles Wilson wrote:
> On 1/11/2011 8:12 PM, Yaakov (Cygwin/X) wrote:
> > 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?
> >
> 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.
I fail to see how mingw-binutils/gcc would go so badly beyond repair
that you would have to revert to gcc3-mingw. Besides setup and its five
dependencies that we have both built, I have built the GTK+ stack (10
packages) and tcl/tk (2 packages). The only real question is ABI
compatibility with mingw.org, as discussed below, but that's just a
matter of using the correct configure flags.
> 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
> working replacement.
>
> I don't think that's acceptable.
Alright, but I really wish we could just be finished with gcc3 already,
it's really past its prime.
> 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?
It didn't come up as an issue in any of my earlier tests. As this is
hardly the only issue that could arise if someone tries calling ld(1)
directly, I wouldn't be overly concerned.
> This presents the following ABI-changing differences:
> --enable-fully-dynamic-strings
> --enable-lto
> I don't think the LTO difference is germane, but the
> fully-dynamic-string part IS.
AFAIK --enable-lto doesn't change ABI; it just builds the extra pieces
necessary for using the -flto flag.
> 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
> be empty).
>
> 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.
I would just confirm that this is indeed not a mistake (IOW it will
remain disabled in future releases), but if so, yes, you should rebuild
gcc as you say. As for the other mingw-* packages, doesn't this only
affect libstdc++, where all those packages are pure C?
> If you mean, dropping support within setup.exe's source repository for
> building with gcc3 -mno-cygwin, fine.
That is what I meant by that sentence, but yes, I really think we should
be dropping gcc3 entirely sooner rather than later.
> 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."
Wouldn't it be "upgrade, but don't add any mingw-* packages until the
second time around"?
Yaakov
