Re: Help compiling gcc 4.2.0

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Lee Rhodes wrote:

>   I picked 4.2.0 because according to gcc.gnu.org it is the "current
> release".  Although, since I have to operate in a cygwin environment I am
> having my doubts.

The 4.2 branch suffered from a long delay post-branch before release,
and so it diverged significantly from mainline.  Since it's a release
branch it's in regression-fix only mode which means a lot of new and
great stuff that's gone into 4.3 since the branch (which was so long ago
- 8 months or so) will never be in 4.2.  This divergence got so bad that
there was some talk of just skipping 4.2 as a release, but too many
people had spent too much time backporting stuff into 4.2 from HEAD that
this was immediately ruled out.

Anyway, my point is that even though 4.2 is the current stable release,
it's quite far removed from the latest in terms of features and
development.  For example, there was a massive upgrade of the copy of
libtool in HEAD, going from a hacked up forked local copy from 2001 to a
current upstream libtool top-of-tree version.  This is particularly
relevant to Cygwin/MinGW because it gives us a fighting chance of
finally getting functional shared target libraries working.  Since this
happened fairly recently and it's not a fix for a regression there's
little chance that it will ever get backported to 4.2, and so 4.2 will
probably be forever broken on Cygwin/MinGW in this area, which means
it's not a very attractive candidate for the Cygwin and MinGW teams to
release stable binaries.

Danny Smith has mentioned that he intends to release a 4.2 MinGW
package, but implicit in that is that he would either backport important
things from 4.3, or locally patch problems (for example his out-of tree
method for building libgcc_s.dll manually by hand), so it's still 4.2
"plus".

That is all just a long winded way of trying to explain why people that
care about gcc on Cygwin/MinGW tend to focus on HEAD and why the 4.2
branch isn't all that interesting.

>   How do I find/apply Dave Korn's patch to stdio.h / newlib?  Is it
> incorporated into any Cygwin contributed snapshots, or is it a pure manual
> source edit?

Sigh.  No, you shouldn't go manually editing anything.  Yes, the fixes
are the Cygwin snapshots, and this is precisely why I said you need to
use a snapshot back three or four messages ago at the beginning of this
thread.  :)

Brian

[Index of Archives]     [Linux C Programming]     [Linux Kernel]     [eCos]     [Fedora Development]     [Fedora Announce]     [Autoconf]     [The DWARVES Debugging Tools]     [Yosemite Campsites]     [Yosemite News]     [Linux GCC]

  Powered by Linux