This is the mail archive of the cygwin-apps mailing list for the Cygwin project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

[RFC] 1.7 Packaging: Toolchain


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

I would like to make some proposals as to setting up the development
toolchain for 1.7:

1) binutils

Thanks to cgf, we've got a current binutils available now; I'm not sure
if binutils itself benefits from 1.7 (save the long path handling).
There is one issue which, while not a showstopper, would be helpful to
fix <http://sourceware.org/bugzilla/show_bug.cgi?id=6744>, which has yet
to see a response from upstream.

2) gcc

There are several issues to consider here:

a) _GLIBCXX_USE_WCHAR_T

Will std::wstring and friends be possible with cygwin-1.7?  If not, is
there anything that can be done to make it possible?

b) 3.4 vs. 4.3

I see little reason to work on gcc-4.3 for cygwin-1.5 at this point.
But this would be a great time to make the jump in release-2.  Dave, I
know you're working on 4.3, so could you give us a status report?
Besides wstring, what is the story with shared gcc libraries (libgcc,
libstdc++, etc.)?

If either of these changes to gcc will be available (particularly 4.3
and/or shared libs), then we'll want that version of gcc available in
release-2 ASAP.

c) -mno-cygwin

IMHO it's time for this insanity to end.  Too many 3PPs abuse Cygwin as
if it were MSYS, and new users just seem to get confused by it.  I
imagine it must make gcc that much harder to maintain as well.

What we should do is treat mingw32 as any other cross-compiling target,
by providing i686-pc-mingw32-* binutils and gcc, and move
/usr/{include,lib}/mingw to /usr/i686-pc-mingw32/ (currently these are
symlinks).

It may not be a pressing issue itself, but while we're making changes
anyway, isn't now the time?

3) libtool

I've been using libtool-2.2 exclusively for three months now, and it's
working pretty well.  A few packages need minor patches to compensate,
but these are usually fairly simple, and some patches are already
available from Gentoo.

As for the LT_OUTPUT in AC_PROG_LIBTOOL issue, as upstream rejected the
patch, we could do without it if we don't have to worry about supporting
libtool-1.5 in release-2.

So Chuck, would you agree with making 2.2 stable in release-2?

4) gettext

BTW Chuck, any chance of a version bump?  0.15 is getting pretty stale
already.

5) cygport

cygport will need some changes for 1.7, and there's a few things that
would greatly benefit from some slight API breakage.  So my plan right
now is to push 0.3.13 soon as stable, create an 0.3 branch for 1.5, and
start working on a 1.7-only version of cygport in HEAD.


Yaakov -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (Cygwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEAREIAAYFAkiIEmEACgkQpiWmPGlmQSMxxACdHMMTrARzqzniGy3lU0stUyfU
qGoAnRmcY9kQGipt/6lkXN8jnbMO1TBZ
=6fV+
-----END PGP SIGNATURE-----


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]