This is the mail archive of the
cygwin-apps
mailing list for the Cygwin project.
Re: ITA: gcc-mingw-* gcc-3 -mno-cygwin support packages; ITP: mingw-binutils/mingw-gcc-* cross compiler
On 1/12/2011 1:04 AM, Yaakov (Cygwin/X) wrote:
> 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).
Well, that's some good data; thanks. I'm just very VERY cautious when
it comes to something as core as a compiler toolchain...
>> 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.
Me too, but I think we have to wait just a BIT longer before we can
obsolete it. :-(
>> Ack. Assuming we can move forward, I'll update as required.
Well, I ought to clarify: I'll keep cygwin's mingw cross compiler in
sync with mingw.org's offerings; I don't *want* to get ahead of them.
OTOH, if its necessary to fix a bug exposed on the cygwin $build
environment, or appears to be a truly "safe" upgrade...I might go ahead
of them.
>> 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");
>>
>> 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.
Ack.
>
>> 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.
OK; I wasn't really sure. It's also one reason "our" compiler has a
slightly newer binutils (20100613 vs 20100624) than the one shipped by
mingw.org.
>> 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.
OK.
> As for the other mingw-* packages, doesn't this only
> affect libstdc++, where all those packages are pure C?
Right.
>> 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.
Well, I agree we should drop gcc3 -mno-cygwin as soon as possible. I
just don't think it is actually possible QUITE yet.
>> 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"?
No, because if you already HAVE mingw-zlib installed, it'll upgrade
automatically. You'd have to manually avoid installing or upgrading ALL
of the following:
mingw-zlib & friends
mingw-bzip2 & friends
mingw-libgcrypt & friends
mingw-xz & friends
mingw-libgpg-error & friends
That's not TOO much of a problem, but you ALSO have to avoid *installing*
mingw-binutils
mingw-gcc*
mingw-pthreads
mingw-w32api
AND avoid upgrading
mingw-runtime
It's mingw-binutils, mingw-gcc-core, and mingw-runtime that are the real
trick, because everybody already has mingw-runtime installed, and
mingw-binutils and mingw-gcc-core are pulled in as requires: because of
A) (mingw) libgcc1.dll, which is in mingw-gcc-core, and is a req of
the updated gcc-mingw "add-on" packages
B) mingw-binutils is needed by the updated gcc-mingw "add-on"
packages unless I play (temporary) games with their setup.hints.
(It's also a req. of mingw-gcc-core, so there's an indirect req.
path as well)
So if I release everything all at once, then I expect poeople will have
to be VERY careful in how they upgrade, playing all sorts of games with
the package chooser list AND ignoring setup.exe warnings about certain
missing dependencies during that FIRST run of setup.exe. (Hence the BIG
WARNING in the initial message in this thread).
--
Chuck