[RFC] 1.7 Packaging: Toolchain

[RFC] 1.7 Packaging: Toolchain

[Yaakov (Cygwin Ports)]

-----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-----

Re: [RFC] 1.7 Packaging: Toolchain

[Corinna Vinschen]

On Jul 24 00:25, Yaakov (Cygwin Ports) wrote:
> 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?

I don't know if that's a problem for std::wstring, but newlib is still
missing the wprintf family of functions.


Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Project Co-Leader          cygwin AT cygwin DOT com
Red Hat

Re: [RFC] 1.7 Packaging: Toolchain

[Brian Dessent]

Corinna Vinschen wrote:

> I don't know if that's a problem for std::wstring, but newlib is still
> missing the wprintf family of functions.

Based on the defintion of GLIBCXX_ENABLE_WCHAR_T in
<http://gcc.gnu.org/viewcvs/trunk/libstdc%2B%2B-v3/acinclude.m4?view=markup>
the list of missing functions before wchar_t can be enabled is:

fgetwc
fgetws
fputwc
fputws
fwide
fwprintf
fwscanf
getwc
getwchar
putwc
putwchar
swprintf
swscanf
ungetwc
vfwprintf
vswprintf
vwprintf
wcsftime
wcstod
wcstok
wprintf
wscanf

Brian

Re: [RFC] 1.7 Packaging: Toolchain

[Christopher Faylor]

On Thu, Jul 24, 2008 at 03:53:16AM -0700, Brian Dessent wrote:
>Corinna Vinschen wrote:
>
>> I don't know if that's a problem for std::wstring, but newlib is still
>> missing the wprintf family of functions.
>
>Based on the defintion of GLIBCXX_ENABLE_WCHAR_T in
><http://gcc.gnu.org/viewcvs/trunk/libstdc%2B%2B-v3/acinclude.m4?view=markup>
>the list of missing functions before wchar_t can be enabled is:
>
>fgetwc
>fgetws
>fputwc
>fputws
>fwide
>fwprintf
>fwscanf
>getwc
>getwchar
>putwc
>putwchar
>swprintf
>swscanf
>ungetwc
>vfwprintf
>vswprintf
>vwprintf
>wcsftime
>wcstod
>wcstok
>wprintf
>wscanf

Huh.  That list is actually smaller than I would have expected.

Can't we get all of these from freebsd?

How about scrapping newlib in favor of freebsd libraries?  I have been
suggesting this for years.  Maybe the timing is wrong since we want to
release Cygwin ASAP but it sure would be nice to be in control of 100%
of Cygwin and not have to wander over to newlib whenever we need to make
changes.

cgf

Re: [RFC] 1.7 Packaging: Toolchain

[Corinna Vinschen]

On Jul 24 15:24, Christopher Faylor wrote:
> On Thu, Jul 24, 2008 at 03:53:16AM -0700, Brian Dessent wrote:
> >Corinna Vinschen wrote:
> >
> >> I don't know if that's a problem for std::wstring, but newlib is still
> >> missing the wprintf family of functions.
> >
> >Based on the defintion of GLIBCXX_ENABLE_WCHAR_T in
> ><http://gcc.gnu.org/viewcvs/trunk/libstdc%2B%2B-v3/acinclude.m4?view=markup>
> >the list of missing functions before wchar_t can be enabled is:
> >
> >fgetwc
> >fgetws
> >fputwc
> >fputws
> >fwide
> >fwprintf
> >fwscanf
> >getwc
> >getwchar
> >putwc
> >putwchar
> >swprintf
> >swscanf
> >ungetwc
> >vfwprintf
> >vswprintf
> >vwprintf
> >wcsftime
> >wcstod
> >wcstok
> >wprintf
> >wscanf
> 
> Huh.  That list is actually smaller than I would have expected.
> 
> Can't we get all of these from freebsd?

Basically, yes, but not quite.  At least the put/get functions and the
fwide function requires integration into the newlib stdio structures and
REENT support.  It's not just a simple drop-in job.

> How about scrapping newlib in favor of freebsd libraries?  I have been
> suggesting this for years.  Maybe the timing is wrong since we want to
> release Cygwin ASAP but it sure would be nice to be in control of 100%
> of Cygwin and not have to wander over to newlib whenever we need to make
> changes.

If we had more man power, maybe.  As it is, I see no chance.  We also
talked about getting the above functions into newlib a few months ago on
cygwin-developers.  Exactly nada happened so far.  As far as I'm
concerned I'm glad that there's at least the libc part we only have to
marginally care about.  Maybe that's something for 1.9.


Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Project Co-Leader          cygwin AT cygwin DOT com
Red Hat

RE: [RFC] 1.7 Packaging: Toolchain

[Dave Korn]

Yaakov (Cygwin Ports) wrote on 24 July 2008 06:26:

> 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?

  If the DLL supports it, then the autoconf tests should detect it and
libstdc++ should build it and everything should "just work".

 
> b) 3.4 vs. 4.3
> 
> I see little reason to work on gcc-4.3 for cygwin-1.5 at this point.

  Well, working on it for one is the same as working on it for the other
anyway.

> 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.)?

  I've got libgcc shared and working fine and correctly, either with a
separate static libgcc_eh, or with it shared, although that's only an option
if you also have shared libstdc++.

  Getting libstdc++ to work shared is being tricky; for some reason
libsupc++ is only built static, which means libtool links it into libstdc++
only to resolve imports, not as objects that need to be exported.  Removing
the --disable-shared libtool tag from libsupc++'s build configuration gets
me what appears to be a complete libstdc++, but it fails in early startup,
probably down to the relocs-in-.rodata issue; and that's where I've got to.
I'm not sure whether to just try and go for a shared-libstdc-static-libsupc
combo, or to try and figure out what needs to be fixed to prevent the relocs
problem - if indeed that's what it is.

> 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.

  That's my plan.

> 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?

  Famous last words.  Yes, that's the scheme we decided on some time ago,
but given how long it's already taking to get vanilla gcc4 working, I was
just going to leave that as it stands for now.

    cheers,
      DaveK
-- 
Can't think of a witty .sigline today....

Re: [RFC] 1.7 Packaging: Toolchain

[Yaakov (Cygwin Ports)]

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

Dave Korn wrote:
|   I've got libgcc shared and working fine and correctly, either with a
| separate static libgcc_eh, or with it shared, although that's only an
option
| if you also have shared libstdc++.
|
|   Getting libstdc++ to work shared is being tricky; for some reason
| libsupc++ is only built static, which means libtool links it into
libstdc++
| only to resolve imports, not as objects that need to be exported.
Removing
| the --disable-shared libtool tag from libsupc++'s build configuration gets
| me what appears to be a complete libstdc++, but it fails in early startup,
| probably down to the relocs-in-.rodata issue; and that's where I've
got to.
| I'm not sure whether to just try and go for a
shared-libstdc-static-libsupc
| combo, or to try and figure out what needs to be fixed to prevent the
relocs
| problem - if indeed that's what it is.

This thread seems to explain the logic behind libsupc++:

http://gcc.gnu.org/ml/gcc/2001-06/msg01886.html

I'd say it makes the most sense to stick with the upstream
shared-libstdc-static-libsupc setup.  I gather that this this isn't
creating a complete libstdc++ though, but I don't see why.  libsupc++ is
being linked in via a convenience lib, which means that it should be
linking the .a with -Wl,--whole-archive, and exporting any symbols
therein.  Which method is being used for symbol exports, and what
exactly is missing?

BTW, what about libg2c/libobjc/libgcj?

|   That's my plan.

May I dare ask for a timeframe?

|   Famous last words.  Yes, that's the scheme we decided on some time ago,
| but given how long it's already taking to get vanilla gcc4 working, I was
| just going to leave that as it stands for now.

I'm not sure I follow.  Is -mno-cygwin part of the "vanilla" gcc now?


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

iEYEAREIAAYFAkiRVpYACgkQpiWmPGlmQSMUDwCgjpDBQYmtpanPQXAjrSccBAJM
fIoAoK8gul9UBxBM0kAxU0hW09NGTiwS
=zdr0
-----END PGP SIGNATURE-----

RE: [RFC] 1.7 Packaging: Toolchain

[Dave Korn]

Dave Korn wrote on 29 July 2008 14:00:

>   Getting libstdc++ to work shared is being tricky; for some reason
> libsupc++ is only built static, which means libtool links it into
> libstdc++ only to resolve imports, not as objects that need to be
> exported.  Removing the --disable-shared libtool tag from libsupc++'s
> build configuration gets me what appears to be a complete libstdc++, but
> it fails in early startup, probably down to the relocs-in-.rodata issue;
> and that's where I've got to. I'm not sure whether to just try and go for
> a shared-libstdc-static-libsupc combo, or to try and figure out what
> needs to be fixed to prevent the relocs problem - if indeed that's what
> it is. 

  It wasn't and I think I've solved it!


    cheers,
      DaveK
-- 
Can't think of a witty .sigline today....