GCC4 status.

GCC4 status.

[Dave Korn]

  Quick progress report.

-  GNAT EH failures fixed.
-  Fixed GIJ (and libjvm) shared builds.
-  Packaging adjusted as per previous discussions.
-  New-and-final release of 3.3.3 to introduce suffixed executables and
alternatives symlinks built, now regtesting.

  Final steps now underway:

-  Add alternatives usage to gcc-4 packaging.
-  Add fix for DLL rebasing problem.
-  Final build and regtest 4.3.2 compiler and check new packaging works.
-  Check new packaging works right for 3.3.3 compiler.

  Immediately after native 4.3.2-2 released:

-  Adding i686-pc-mingw32 cross compiler build to gcc-4 cygport file (already
under way, last build failed with "libgomp needs pthreads" error - need to get
myself win32-pthreads for MinGW, I think).
-  Minor hacks to package generation for mingw x-compiler.
-  Build, regtest, package test and upload.

  (Then I'll start work on 4.5.0 upstream; I want to get upstream gcc using
DW2 EH by default, fix weak symbol handling, and we'll see about those foreign
frames.)


    cheers,
      DaveK

Re: GCC4 status.

[Dave Korn]

Dave Korn wrote:

> -  New-and-final release of 3.3.3 to introduce suffixed executables and

  Dur.  I mean 3.4.4.

> alternatives symlinks built, now regtesting.

  BTW, I've chosen a release number of 3.4.4-999 for this, because I felt like
no other version number says "End of the line" quite so well.  I needed to
skip at least one version number because I used 3.4.4-4 for a custom build
that had some patches not suitable for upstream release, and I don't want to
have conflicting identically numbered versions floating around out there.  (If
there's going to be a technical problem with that, please let me know and I'll
respin it, but I'd rather not do so for merely cosmetic bikeshed reasons.)

  The plan is to make this the last ever release on 1.5, and the last ever
release of 3.3.3 (punting it into status as a legacy compiler), and hopefully
the final experimental release of gcc 4.  It'll introduce alternatives usage
so that the old 3 and new 4 can be side-by-side installed with either one the
default when you don't specify, and I'd like to release them ASAP.

  I'll then have a bit of time to get the mingw cross working while people
play with the DLLs and shake out any bugs, and assuming nothing massive crops
up I'll rapidly spin an upgrade to the new 4.3.3 and take it out of
experimental status, so it becomes the default 1.7 compiler.

    cheers,
      DaveK

Re: GCC4 status.

[Yaakov (Cygwin/X)]

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

Dave Korn wrote:
> -  Adding i686-pc-mingw32 cross compiler build to gcc-4 cygport file (already
> under way, last build failed with "libgomp needs pthreads" error - need to get
> myself win32-pthreads for MinGW, I think).

cygport's cross.cygclass needs some serious work, so if you're using it,
please let me know what enhancements you need.


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

iEYEAREIAAYFAkmjcIQACgkQpiWmPGlmQSP3VgCgu8K2QpQJBhnoRb1s5Hi6igMQ
PiUAn2kB1HBQBoBKimyLVlWnjHD21kjy
=usXM
-----END PGP SIGNATURE-----

Re: GCC4 status.

[Dave Korn]

Yaakov (Cygwin/X) wrote:

> Dave Korn wrote:
>> -  Adding i686-pc-mingw32 cross compiler build to gcc-4 cygport file (already
>> under way, last build failed with "libgomp needs pthreads" error - need to get
>> myself win32-pthreads for MinGW, I think).
> 
> cygport's cross.cygclass needs some serious work, so if you're using it,
> please let me know what enhancements you need.

  Was just planning on doing a hideous hack where I wrap large chunks of my
.cygport file in the equivalent of #ifdefs! :)  Don't think it's necessarily
suitable for the class file anyway, it's going to be a fairly non-standard
x-compiler in that it won't go into the usual $prefix/$target sysroot, it's
going to look for headers and libs directly where they live under the native
prefix in /usr/include/mingw /usr/include/w32api /lib/mingw and /lib/w32api,
and it's going to use the native 'as' and 'ld'.  So it's going to be an ugly
hybrid beast....

    cheers,
      DaveK

Re: GCC4 status.

[Charles Wilson]

Dave Korn wrote:
> it's going to be a fairly non-standard
> x-compiler in that it won't go into the usual $prefix/$target sysroot, it's
> going to look for headers and libs directly where they live under the native
> prefix in /usr/include/mingw /usr/include/w32api /lib/mingw and /lib/w32api,
> and it's going to use the native 'as' and 'ld'.  So it's going to be an ugly
> hybrid beast....

Why? Why shouldn't it just be a normal, vanilla, cross-compiler? Just
because we don't want two copies of w32api and mingw-runtime, or a
cross-ld/cross-as?

I think the maintenance headaches associated with an "ugly hybrid beast"
outweigh those other, tiny, costs...

--
Chuck

Re: GCC4 status.

[Christopher Faylor]

On Tue, Feb 24, 2009 at 12:05:20AM -0500, Charles Wilson wrote:
>Dave Korn wrote:
>> it's going to be a fairly non-standard
>> x-compiler in that it won't go into the usual $prefix/$target sysroot, it's
>> going to look for headers and libs directly where they live under the native
>> prefix in /usr/include/mingw /usr/include/w32api /lib/mingw and /lib/w32api,
>> and it's going to use the native 'as' and 'ld'.  So it's going to be an ugly
>> hybrid beast....
>
>Why? Why shouldn't it just be a normal, vanilla, cross-compiler? Just
>because we don't want two copies of w32api and mingw-runtime, or a
>cross-ld/cross-as?
>
>I think the maintenance headaches associated with an "ugly hybrid beast"
>outweigh those other, tiny, costs...

I agree.  I think we should relocate mingw and w32api into standard
locations.  That was part of the reason for getting rid of -mno-cygwin.

cgf

Re: GCC4 status.

[Charles Wilson]

Christopher Faylor wrote:
> On Tue, Feb 24, 2009 at 12:05:20AM -0500, Charles Wilson wrote:
>> Dave Korn wrote:
>>> it's going to be a fairly non-standard
>>> x-compiler in that it won't go into the usual $prefix/$target sysroot, it's
>>> going to look for headers and libs directly where they live under the native
>>> prefix in /usr/include/mingw /usr/include/w32api /lib/mingw and /lib/w32api,
>>> and it's going to use the native 'as' and 'ld'.  So it's going to be an ugly
>>> hybrid beast....
>> Why? Why shouldn't it just be a normal, vanilla, cross-compiler? Just
>> because we don't want two copies of w32api and mingw-runtime, or a
>> cross-ld/cross-as?
>>
>> I think the maintenance headaches associated with an "ugly hybrid beast"
>> outweigh those other, tiny, costs...
> 
> I agree.  I think we should relocate 

relocate?  But the regular cygwin gcc needs at least w32api, and that
location is hardcoded in its specs file.  Which means that relocate
implies -> respin gcc-3.4.4-999, and respin gcc-4.2.3.  And it doesn't
really make sense for the cygwin-gcc specs to specify "always look in
/usr/i686-pc-mingw32/include/[w32api]". Whuh, huh? *-mingw32?

It makes more sense to me that we have two different w32api packages:
the "regular" one that installs into /usr/[include|lib]/w32api, and a
mingw-cross-w32api that installs into
/usr/${mingw-triple}/[include|lib]/[w32api].

mingw-runtime...sure, that could probably be "relocated" without
trouble.  I don't think the "regular" cygwin gcc should care about that.

> mingw and w32api into standard
> locations.  That was part of the reason for getting rid of -mno-cygwin.

--
Chuck

Re: GCC4 status.

[Christopher Faylor]

On Tue, Feb 24, 2009 at 12:27:47AM -0500, Charles Wilson wrote:
>Christopher Faylor wrote:
>> On Tue, Feb 24, 2009 at 12:05:20AM -0500, Charles Wilson wrote:
>>> Dave Korn wrote:
>>>> it's going to be a fairly non-standard
>>>> x-compiler in that it won't go into the usual $prefix/$target sysroot, it's
>>>> going to look for headers and libs directly where they live under the native
>>>> prefix in /usr/include/mingw /usr/include/w32api /lib/mingw and /lib/w32api,
>>>> and it's going to use the native 'as' and 'ld'.  So it's going to be an ugly
>>>> hybrid beast....
>>> Why? Why shouldn't it just be a normal, vanilla, cross-compiler? Just
>>> because we don't want two copies of w32api and mingw-runtime, or a
>>> cross-ld/cross-as?
>>>
>>> I think the maintenance headaches associated with an "ugly hybrid beast"
>>> outweigh those other, tiny, costs...
>> 
>> I agree.  I think we should relocate 
>
>relocate?  But the regular cygwin gcc needs at least w32api, and that
>location is hardcoded in its specs file.

AFAIK, a normal Cygwin installation doesn't use the w32api header files
unless you're building a hybrid Cygwin/Windows program.  That is a
pretty sad beast but I guess people really do use that.  I guess we
can't think about removing -mno-win32.  A limited number of libraries
are used so it wouldn't make sense to move them around.

I don't know how things have changed since I gave up the gcc reins
but it used to be that the installation created a /usr/i686-pc-mingw32/
hierarchy.  I always thought that any future cross-compiler would just
actually populate that.

>implies -> respin gcc-3.4.4-999, and respin gcc-4.2.3.  And it doesn't
>really make sense for the cygwin-gcc specs to specify "always look in
>/usr/i686-pc-mingw32/include/[w32api]". Whuh, huh? *-mingw32?
>
>It makes more sense to me that we have two different w32api packages:
>the "regular" one that installs into /usr/[include|lib]/w32api, and a
>mingw-cross-w32api that installs into
>/usr/${mingw-triple}/[include|lib]/[w32api].

Two versions?  Whuh, Huh?  When is that ever a good idea?

What I would like to see is all of the Windows stuff isolated as much as
possible from the Cygwin.  Possibly all of the windows-only stuff could
either install in a windows hierarchy or a mingw hierarchy and symlinks
into /usr/include and (sparingly) /usr/lib could be made.

>mingw-runtime...sure, that could probably be "relocated" without
>trouble.  I don't think the "regular" cygwin gcc should care about that.

I believe that gegular cygwin gcc only cares about w32api for finding:
libuser32.a libkernel32.a libadvapi32.a libshell32.a .  It adds the
w32api include when -mwindows is specified and, like I said, I guess we
can't delete that now.  But we can make it clearer where these things
come from by installing them in a mingw-specific location and symlinking
them from there.

cgf

Re: GCC4 status.

[Yaakov (Cygwin/X)]

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

Christopher Faylor wrote:
> AFAIK, a normal Cygwin installation doesn't use the w32api header files
> unless you're building a hybrid Cygwin/Windows program.  That is a
> pretty sad beast but I guess people really do use that.  I guess we
> can't think about removing -mno-win32.  A limited number of libraries
> are used so it wouldn't make sense to move them around.

Some multimedia packages use mmsystem.h/libwinmm for low-level functions
such as optical disc access.  OTOH I would be thrilled if winsock.h and
friends (which conflict with cygwin's sys/socket.h) would be out of the
default search path.

> Two versions?  Whuh, Huh?  When is that ever a good idea?
> 
> What I would like to see is all of the Windows stuff isolated as much as
> possible from the Cygwin.  Possibly all of the windows-only stuff could
> either install in a windows hierarchy or a mingw hierarchy and symlinks
> into /usr/include and (sparingly) /usr/lib could be made.

That may work, but we would have to decide very carefully what goes into
/usr and what not.


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

iEYEAREIAAYFAkmjlksACgkQpiWmPGlmQSP9VQCdFc8eGBvrXRmRtpJf45Hl8Lcw
BKoAni4NGsXg6S7NjP+XxVr6BUQg2AQt
=t04W
-----END PGP SIGNATURE-----

Re: GCC4 status.

[Corinna Vinschen]

On Feb 24 00:27, Charles Wilson wrote:
> Christopher Faylor wrote:
> > On Tue, Feb 24, 2009 at 12:05:20AM -0500, Charles Wilson wrote:
> >> Dave Korn wrote:
> >>> it's going to be a fairly non-standard
> >>> x-compiler in that it won't go into the usual $prefix/$target sysroot, it's
> >>> going to look for headers and libs directly where they live under the native
> >>> prefix in /usr/include/mingw /usr/include/w32api /lib/mingw and /lib/w32api,
> >>> and it's going to use the native 'as' and 'ld'.  So it's going to be an ugly
> >>> hybrid beast....
> >> Why? Why shouldn't it just be a normal, vanilla, cross-compiler? Just
> >> because we don't want two copies of w32api and mingw-runtime, or a
> >> cross-ld/cross-as?
> >>
> >> I think the maintenance headaches associated with an "ugly hybrid beast"
> >> outweigh those other, tiny, costs...
> > 
> > I agree.  I think we should relocate 
> 
> relocate?  But the regular cygwin gcc needs at least w32api, and that
> location is hardcoded in its specs file.  Which means that relocate
> implies -> respin gcc-3.4.4-999, and respin gcc-4.2.3.  And it doesn't
> really make sense for the cygwin-gcc specs to specify "always look in
> /usr/i686-pc-mingw32/include/[w32api]". Whuh, huh? *-mingw32?
> 
> It makes more sense to me that we have two different w32api packages:
> the "regular" one that installs into /usr/[include|lib]/w32api, and a
> mingw-cross-w32api that installs into
> /usr/${mingw-triple}/[include|lib]/[w32api].

IMO it would be much easier to keep mingw and w32api in place and just
create matching symlinks in /usr/i686-pc-mingw32.  This way you can
create a standard compiler *and* keep the include and lib files in
place.  We can't move all of it out of the way anyway.  We need at least
the mingw DLL in /bin since some Cygwin tools rely on it.  And using
w32api headers and linking against Windows libs in Cygwin applications
might not be very POSIX compliant, but is necessary.  Every Cygwin
application you link must be linked against kernel32.dll and friends.
There's also still a lot of Windows functionality we can't cover in
Cygwin.  USB access as in libusb-win32 comes to mind.


Corinna

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

Re: GCC4 status.

[Dave Korn]

Charles Wilson wrote:
> Dave Korn wrote:
>> it's going to be a fairly non-standard
>> x-compiler in that it won't go into the usual $prefix/$target sysroot, it's
>> going to look for headers and libs directly where they live under the native
>> prefix in /usr/include/mingw /usr/include/w32api /lib/mingw and /lib/w32api,
>> and it's going to use the native 'as' and 'ld'.  So it's going to be an ugly
>> hybrid beast....
> 
> Why? Why shouldn't it just be a normal, vanilla, cross-compiler? Just
> because we don't want two copies of w32api and mingw-runtime, or a
> cross-ld/cross-as?

  Yep, these were my original reasons.

> I think the maintenance headaches associated with an "ugly hybrid beast"
> outweigh those other, tiny, costs...

  Well, I'm as allergic as cgf seems to be to the idea of having
duplicated-and-potentially-inconsistent sets of the same files around the
place, but as the downthread consensus seems to be settling on, we can
rearrange things to have a proper $prefix/$target dir and build a proper one.
 (More to come in follow-on responses.)

    cheers,
      DaveK

Re: GCC4 status.

[Charles Wilson]

Dave Korn wrote:
>   Well, I'm as allergic as cgf seems to be to the idea of having
> duplicated-and-potentially-inconsistent sets of the same files around the
> place,

D'oh. I was forgetting that the cross compiler would be a cygwin app.
For some reason I was thinking that it wouldn't be able to understand
symlinks, so it needed actual files (copies) for its "relocated" w32api
and mingw-runtime headers/libs.  Then again, the native cygwin compiler
is obviously a cygwin app, so it's just a reasonable to put the "real"
files in /usr/i686-pc-mingw32 and, as cgf mentioned, populate
/usr/[include|lib]/[w32api] with symlinks.

For mingw-runtime, the only reason not to completely relocate /ITS/
headers, libs, and objects (but not mingwm10.dll and docs) is backwards
compatibility with existing -mno-cygwin-capable compilers, or if Dave
doesn't want to respin gcc-3.4.4-999 to look in the new location. The
new cygwin-only gcc shouldn't care about mingw-runtime at all.

To close out the "relocate vs. copy vs. symlink" subthread: I was also
thinking of the "two copies" problem from the w32api-maintainer's
perspective. I don't consider the following:
   $ configure --prefix=/usr/i686-pc-mingw32 \
	--includedir=${prefix}/include/w32api \
	--libdir=${prefix}/lib/w32api
   $ make && make install DESTDIR=/tmp/foo
   ...
   $ configure --prefix=/usr \
	--includedir=${prefix}/include/w32api \
	--libdir=${prefix}/lib/w32api
   $ make && make install DESTDIR=/tmp/foo
   ...
   $ make-pkg w32api /tmp/foo/
   or
   $ make-pkg w32api /tmp/foo/usr
   $ make-pkg mingw-cross-w32api /tmp/foo/i686-pc-mingw32
to be very prone to inconsistency.  Heck, the pkg-build script could
even include a giant "diff -urN" sanity check.

However, if end-users are in the habit of editing stuff in
/usr/include/w32api/ in-place, or (in the separate packages case) don't
upgrade both related packages together for whatever reason, then...yeah,
ok, things could get messed up.

> but as the downthread consensus seems to be settling on, we can
> rearrange things to have a proper $prefix/$target dir and build a proper one.
>  (More to come in follow-on responses.)

Hmm. Maybe the "final" gcc-3.4.4-999 should be gcc-3.4.4-990. Just in
case there are unanticipated wrinkles. <g>

--
Chuck

Re: GCC4 status.

[Dave Korn]

Charles Wilson wrote:

> D'oh. I was forgetting that the cross compiler would be a cygwin app.
> For some reason I was thinking that it wouldn't be able to understand
> symlinks, so it needed actual files (copies) for its "relocated" w32api
> and mingw-runtime headers/libs.  Then again, the native cygwin compiler
> is obviously a cygwin app, so it's just a reasonable to put the "real"
> files in /usr/i686-pc-mingw32 and, as cgf mentioned, populate
> /usr/[include|lib]/[w32api] with symlinks.

  Of course, the cygwin1.dll itself is a MinGW app, so should live in
/usr/i686-pc-mingw32/bin !

> For mingw-runtime, the only reason not to completely relocate /ITS/
> headers, libs, and objects (but not mingwm10.dll and docs) is backwards
> compatibility with existing -mno-cygwin-capable compilers

  Yep, so since it's just a symlink that's what we'll do.

> Hmm. Maybe the "final" gcc-3.4.4-999 should be gcc-3.4.4-990. Just in
> case there are unanticipated wrinkles. <g>

  Nah, I'll just append an extra '9' if I ever need to respin it, thus
indicating that the final release ever would be gcc-3.4.4-aleph-null, which I
will be approaching asymptotically!  :-)


    cheers,
      DaveK

Re: GCC4 status.

[Christopher Faylor]

On Tue, Feb 24, 2009 at 09:29:36AM -0500, Charles Wilson wrote:
>Dave Korn wrote:
>>   Well, I'm as allergic as cgf seems to be to the idea of having
>> duplicated-and-potentially-inconsistent sets of the same files around the
>> place,
>
>D'oh. I was forgetting that the cross compiler would be a cygwin app.
>For some reason I was thinking that it wouldn't be able to understand
>symlinks, so it needed actual files (copies) for its "relocated" w32api
>and mingw-runtime headers/libs.  Then again, the native cygwin compiler
>is obviously a cygwin app, so it's just a reasonable to put the "real"
>files in /usr/i686-pc-mingw32 and, as cgf mentioned, populate
>/usr/[include|lib]/[w32api] with symlinks.
>
>For mingw-runtime, the only reason not to completely relocate /ITS/
>headers, libs, and objects (but not mingwm10.dll and docs) is backwards
>compatibility with existing -mno-cygwin-capable compilers, or if Dave
>doesn't want to respin gcc-3.4.4-999 to look in the new location. The
>new cygwin-only gcc shouldn't care about mingw-runtime at all.
>
>To close out the "relocate vs. copy vs. symlink" subthread: I was also
>thinking of the "two copies" problem from the w32api-maintainer's
>perspective. I don't consider the following:
>   $ configure --prefix=/usr/i686-pc-mingw32 \
>	--includedir=${prefix}/include/w32api \
>	--libdir=${prefix}/lib/w32api
>   $ make && make install DESTDIR=/tmp/foo
>   ...
>   $ configure --prefix=/usr \
>	--includedir=${prefix}/include/w32api \
>	--libdir=${prefix}/lib/w32api
>   $ make && make install DESTDIR=/tmp/foo
>   ...
>   $ make-pkg w32api /tmp/foo/
>   or
>   $ make-pkg w32api /tmp/foo/usr
>   $ make-pkg mingw-cross-w32api /tmp/foo/i686-pc-mingw32
>to be very prone to inconsistency.  Heck, the pkg-build script could
>even include a giant "diff -urN" sanity check.

You're not thinking about this from the proper perspective if you think
that the package maintainer is the one who would have problems with two
copies.

cgf

Re: GCC4 status.

[Christopher Faylor]

On Tue, Feb 24, 2009 at 10:14:51AM +0100, Corinna Vinschen wrote:
>On Feb 24 00:27, Charles Wilson wrote:
>> Christopher Faylor wrote:
>> > On Tue, Feb 24, 2009 at 12:05:20AM -0500, Charles Wilson wrote:
>> >> Dave Korn wrote:
>> >>> it's going to be a fairly non-standard
>> >>> x-compiler in that it won't go into the usual $prefix/$target sysroot, it's
>> >>> going to look for headers and libs directly where they live under the native
>> >>> prefix in /usr/include/mingw /usr/include/w32api /lib/mingw and /lib/w32api,
>> >>> and it's going to use the native 'as' and 'ld'.  So it's going to be an ugly
>> >>> hybrid beast....
>> >> Why? Why shouldn't it just be a normal, vanilla, cross-compiler? Just
>> >> because we don't want two copies of w32api and mingw-runtime, or a
>> >> cross-ld/cross-as?
>> >>
>> >> I think the maintenance headaches associated with an "ugly hybrid beast"
>> >> outweigh those other, tiny, costs...
>> > 
>> > I agree.  I think we should relocate 
>> 
>> relocate?  But the regular cygwin gcc needs at least w32api, and that
>> location is hardcoded in its specs file.  Which means that relocate
>> implies -> respin gcc-3.4.4-999, and respin gcc-4.2.3.  And it doesn't
>> really make sense for the cygwin-gcc specs to specify "always look in
>> /usr/i686-pc-mingw32/include/[w32api]". Whuh, huh? *-mingw32?
>> 
>> It makes more sense to me that we have two different w32api packages:
>> the "regular" one that installs into /usr/[include|lib]/w32api, and a
>> mingw-cross-w32api that installs into
>> /usr/${mingw-triple}/[include|lib]/[w32api].
>
>IMO it would be much easier to keep mingw and w32api in place and just
>create matching symlinks in /usr/i686-pc-mingw32.  This way you can
>create a standard compiler *and* keep the include and lib files in
>place.  We can't move all of it out of the way anyway.  We need at least
>the mingw DLL in /bin since some Cygwin tools rely on it.

Maybe I'm missing something but I just checked every executable in my
bin area and I didn't find any that relied on a mingw DLL.

>w32api headers and linking against Windows libs in Cygwin applications
>might not be very POSIX compliant, but is necessary.  Every Cygwin
>application you link must be linked against kernel32.dll and friends.

That's why I talked about making selective symlinks into /usr/lib.

Maybe, to be kind, we could create a /usr/mingw directory so that people
could add -L/usr/mingw/lib to their link lines rather than -L/usr/i686-pc-mingw/lib .

>There's also still a lot of Windows functionality we can't cover in
>Cygwin.  USB access as in libusb-win32 comes to mind.

I don't see what a separate package has to do with anything.  I'm just
talking about making sure that the mingw packages live where they should
rather than where they have been historically - and I'm actually to
blame for some of the poor choices for these directories.

I wouldn't normally suggest such a radical change but since we're talking
about releasing new versions of gcc this seems like a good time to clean
things up.

cgf

Re: GCC4 status.

[Corinna Vinschen]

On Feb 24 11:35, Christopher Faylor wrote:
> On Tue, Feb 24, 2009 at 10:14:51AM +0100, Corinna Vinschen wrote:
> >IMO it would be much easier to keep mingw and w32api in place and just
> >create matching symlinks in /usr/i686-pc-mingw32.  This way you can
> >create a standard compiler *and* keep the include and lib files in
> >place.  We can't move all of it out of the way anyway.  We need at least
> >the mingw DLL in /bin since some Cygwin tools rely on it.
> 
> Maybe I'm missing something but I just checked every executable in my
> bin area and I didn't find any that relied on a mingw DLL.

My fault.  I blindly assumed that cygcheck and strace link against the
mingw dll but they really just need msvcrt.dll.

> >w32api headers and linking against Windows libs in Cygwin applications
> >might not be very POSIX compliant, but is necessary.  Every Cygwin
> >application you link must be linked against kernel32.dll and friends.
> 
> That's why I talked about making selective symlinks into /usr/lib.

and /usr/include, please.

> Maybe, to be kind, we could create a /usr/mingw directory so that people
> could add -L/usr/mingw/lib to their link lines rather than -L/usr/i686-pc-mingw/lib .

I don't think that's necessary.  I just dread a situation where you
suddenly don't have w32api in the default include and lib search paths.
I don't have problems with mingw.  Just w32api is essential IMO.  If I
missed this in the discussion up to this point, feel free to ignore me.
Otherwise, just make sure that w32api is searched by default.


Corinna

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

Re: GCC4 status.

[Dave Korn]

Corinna Vinschen wrote:

> I don't think that's necessary.  I just dread a situation where you
> suddenly don't have w32api in the default include and lib search paths.
> I don't have problems with mingw.  Just w32api is essential IMO.  If I
> missed this in the discussion up to this point, feel free to ignore me.
> Otherwise, just make sure that w32api is searched by default.

  Back-compat is a given, don't worry!

    cheers,
      DaveK

Re: GCC4 status.

[Corinna Vinschen]

On Feb 24 18:22, Dave Korn wrote:
> Corinna Vinschen wrote:
> 
> > I don't think that's necessary.  I just dread a situation where you
> > suddenly don't have w32api in the default include and lib search paths.
> > I don't have problems with mingw.  Just w32api is essential IMO.  If I
> > missed this in the discussion up to this point, feel free to ignore me.
> > Otherwise, just make sure that w32api is searched by default.
> 
>   Back-compat is a given, don't worry!

Thanks, Dave.  While we're talking gcc-4, may I ask about two really
annoying messages I'd rather not like to see in future unless I switch
them on with a special --i-wanna-see-every-single-detail-whatever-the-cost
option?

#1)

  sftp.c:368: warning: 'opterr' redeclared without dllimport attribute:
  previous dllimport ignored

  Yes, well, so what?

#2)

  /usr/lib/gcc/i686-pc-cygwin/4.3.2/../../../../i686-pc-cygwin/bin/ld:
  warning: auto-importing has been activated without --enable-auto-import
  specified on the command line.
  This should work unless it involves constant data structures referencing
  symbols from auto-imported DLLs.

  *Sob*  Yes, officer, I confess everything!  But *please* don't tell
  me this every time I dare to link an application.

Is there any chance to get rid of this really useless stuff upstream?


Corinna

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

Re: GCC4 status.

[Dave Korn]

Corinna Vinschen wrote:

> #1)
> 
>   sftp.c:368: warning: 'opterr' redeclared without dllimport attribute:
>   previous dllimport ignored
> 
>   Yes, well, so what?

  This one IIRC has some significance.  If you declare any extern symbols at
all with dllimport attributes, it disables auto-import altogether.  So a stray
definition like that can break linking all the other functions that would
normally be auto-imported.

> #2)
> 
>   /usr/lib/gcc/i686-pc-cygwin/4.3.2/../../../../i686-pc-cygwin/bin/ld:
>   warning: auto-importing has been activated without --enable-auto-import
>   specified on the command line.
>   This should work unless it involves constant data structures referencing
>   symbols from auto-imported DLLs.
> 
>   *Sob*  Yes, officer, I confess everything!  But *please* don't tell
>   me this every time I dare to link an application.
> 
> Is there any chance to get rid of this really useless stuff upstream?

  I don't know.  We could turn on auto import globally but that will pessimize
a whole bunch of stuff that needn't be affected.  We could discard the warning
altogether but then people would get silent failures.

  What would be best of all would be to only issue the warning if a const data
structure reference of the kind mentioned actually occurs.  I haven't looked
to see if that's possible to detect yet, but it would be a nice fix for
upstream ld.

  As a workaround, the sources could always be fixed.  Inconsistent
declarations *is* a correctness issue, after all, and it's usually trivial to
add an item to LDFLAGS.

  Also, perhaps as a half-way compromise measure, auto import could be enabled
in the GCC specs for just C++/ObjC++/Java.  I don't know what's for the best
yet, does anyone else have any suggestions?

    cheers,
      DaveK

Re: GCC4 status.

[Corinna Vinschen]

On Feb 25 17:30, Dave Korn wrote:
> Corinna Vinschen wrote:
> 
> > #1)
> > 
> >   sftp.c:368: warning: 'opterr' redeclared without dllimport attribute:
> >   previous dllimport ignored
> > 
> >   Yes, well, so what?
> 
>   This one IIRC has some significance.  If you declare any extern symbols at
> all with dllimport attributes, it disables auto-import altogether.  So a stray
> definition like that can break linking all the other functions that would
> normally be auto-imported.

So why does it do that at all: "previous dllimport ignored"?
It shouldn't do that.  The dllimport should have precedence, IMHO.

> > #2)
> > 
> >   /usr/lib/gcc/i686-pc-cygwin/4.3.2/../../../../i686-pc-cygwin/bin/ld:
> >   warning: auto-importing has been activated without --enable-auto-import
> >   specified on the command line.
> >   This should work unless it involves constant data structures referencing
> >   symbols from auto-imported DLLs.
> > 
> >   *Sob*  Yes, officer, I confess everything!  But *please* don't tell
> >   me this every time I dare to link an application.
> > 
> > Is there any chance to get rid of this really useless stuff upstream?
> 
>   I don't know.  We could turn on auto import globally but that will pessimize
> a whole bunch of stuff that needn't be affected.  We could discard the warning
> altogether but then people would get silent failures.

I think auto import should be the default.  You don't have this problem
and the message on any other platform.  Why isn't the default setting so
that we get what other platforms get, too?  I never had the case so far
where auto import would have hurt.  Am I just maintaining too simple
projects?

>   As a workaround, the sources could always be fixed.  Inconsistent
> declarations *is* a correctness issue, after all, and it's usually trivial to
> add an item to LDFLAGS.

There's only so much platform uglification put up with in the upstream
OpenSSH sources...

>   Also, perhaps as a half-way compromise measure, auto import could be enabled
> in the GCC specs for just C++/ObjC++/Java.  I don't know what's for the best
> yet, does anyone else have any suggestions?

...which are written in plain C, btw.  So this compromise is none
for a lot of packages in the Cygwin distro, not only for OpenSSH.


Corinna

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

Re: GCC4 status.

[Charles Wilson]

Corinna Vinschen wrote:
>   /usr/lib/gcc/i686-pc-cygwin/4.3.2/../../../../i686-pc-cygwin/bin/ld:
>   warning: auto-importing has been activated without --enable-auto-import
>   specified on the command line.
>   This should work unless it involves constant data structures referencing
>   symbols from auto-imported DLLs.
> 
>   *Sob*  Yes, officer, I confess everything!  But *please* don't tell
>   me this every time I dare to link an application.
> 
> Is there any chance to get rid of this really useless stuff upstream?

This is a binutils, not gcc, issue (unless you just want gcc's specs
file to automatically pass the option to ld.  But then, how does Bruno
turn it off, as he does, for gettext and libintl?  ld would see both
--enable (from specs) and --disable (from Bruno's cmdline -- but do we
guarantee which order specs-derived and cmdline-derived options are
delivered to ld?).  I think it's better to change cygwin-ld's default
behavior than to try to work around the warning in gcc's specs file.


Now, ld for pe[i]-386 already (as of 2008/11/24) defaults to
--enable-runtime-pseudo-reloc-v1.
http://sourceware.org/cgi-bin/cvsweb.cgi/src/ld/emultempl/pe.em.diff?r1=1.137&r2=1.138&cvsroot=src&f=h

This doesn't make much sense unless we also default to
--enable-auto-import, which is a one-line change to the same file at
line 148:

-link_info.pei386_auto_import = -1;
+link_info.pei386_auto_import = 1; /* default to enabled */

There might be pushback from other pe platforms, but changing the
default behavior for cygwin is in cgf's court.

--
Chuck

Re: GCC4 status.

[Charles Wilson]

Dave Korn wrote:
> Corinna Vinschen wrote:
>> #2)
>>
>>   /usr/lib/gcc/i686-pc-cygwin/4.3.2/../../../../i686-pc-cygwin/bin/ld:
>>   warning: auto-importing has been activated without --enable-auto-import
>>   specified on the command line.
>>   This should work unless it involves constant data structures referencing
>>   symbols from auto-imported DLLs.
>>
>>   *Sob*  Yes, officer, I confess everything!  But *please* don't tell
>>   me this every time I dare to link an application.
>>
>> Is there any chance to get rid of this really useless stuff upstream?
> 
>   I don't know.  We could turn on auto import globally but that will pessimize
> a whole bunch of stuff that needn't be affected.  We could discard the warning
> altogether but then people would get silent failures.

It's already on by default. The variable
link_info.pei386_auto_import
is currently initialized to -1, which means "Do it, but complain".

The only thing changing that initialization to "1" would do, would be to
stop complaining.

You already have to use explicitly --disable-auto-import to turn it off.

>  What would be best of all would be to only issue the warning if a const data
> structure reference of the kind mentioned actually occurs.  I haven't looked
> to see if that's possible to detect yet, but it would be a nice fix for
> upstream ld.

Actually, with Kai's recent changes, IF we
 (1) modified cygwin's src/winsup/cygwin/lib/pseudo-reloc.c file to
support -v2 psuedo-relocs
 (2) EVENTUALLY, after much testing, changed cygwin-ld's default reloc
mode from (current: not enabled; CVS ld: v1 enabled) to v2 enabled, THEN

we can have const structure references (and "complex" data type
references) that can be updated without error.

I think.

See:
http://cygwin.com/ml/cygwin-developers/2009-01/msg00009.html
and following thread, as well as embedded links in the referenced message.

> As a workaround, the sources could always be fixed.  Inconsistent
> declarations *is* a correctness issue, after all, and it's usually trivial to
> add an item to LDFLAGS.
> 
>   Also, perhaps as a half-way compromise measure, auto import could be enabled
> in the GCC specs for just C++/ObjC++/Java.  I don't know what's for the best
> yet, does anyone else have any suggestions?

See previous message.

--
Chuck

Re: GCC4 status.

[Yaakov (Cygwin/X)]

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

Charles Wilson wrote:
> This is a binutils, not gcc, issue (unless you just want gcc's specs
> file to automatically pass the option to ld.  But then, how does Bruno
> turn it off, as he does, for gettext and libintl? 

Maybe we tell him how things should be done on Cygwin, rather than *him*
telling *us* how Cygwin should work.


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

iEYEAREIAAYFAkmmENgACgkQpiWmPGlmQSNyagCgkdfmmWUhz53FIWRZVUrlgC8C
3dgAn0W+T3GYr6SScz3ejWtRYqJXHOvv
=RsfB
-----END PGP SIGNATURE-----

Re: GCC4 status.

[Charles Wilson]

Yaakov (Cygwin/X) wrote:
> Charles Wilson wrote:
>> This is a binutils, not gcc, issue (unless you just want gcc's specs
>> file to automatically pass the option to ld.  But then, how does Bruno
>> turn it off, as he does, for gettext and libintl? 
> 
> Maybe we tell him how things should be done on Cygwin, rather than *him*
> telling *us* how Cygwin should work.

I just picked gettext/libintl as a known example of existing projects
where --disable-auto-import is the desired (by *somebody*, doesn't
matter who or why) behavior.  There could be other end-users who, for
whatever reason, want to avoid auto-import.  Putting
--enable-auto-import into the specs file makes that...tricky.

--
Chuck

Re: GCC4 status.

[Dave Korn]

Charles Wilson wrote:
> Yaakov (Cygwin/X) wrote:
>> Charles Wilson wrote:

>>> But then, how does Bruno
>>> turn it off, as he does, for gettext and libintl? 

>> Maybe we tell him how things should be done on Cygwin, rather than *him*
>> telling *us* how Cygwin should work.

> There could be other end-users who, for
> whatever reason, want to avoid auto-import.  Putting
> --enable-auto-import into the specs file makes that...tricky.

  Yeh, I think I agree that we shouldn't block it altogether.  I'm fully in
favour of changing the default in upstream ld.

    cheers,
      DaveK

Re: GCC4 status.

[Dave Korn]

Corinna Vinschen wrote:

> So why does it do that at all: "previous dllimport ignored"?
> It shouldn't do that.  The dllimport should have precedence, IMHO.

  I don't know why it does that, it's just the behaviour of vanilla upstream
GCC.  I think it might be important, and have a vague memory of some PR
relating to this in the bugzilla.  I'll take a closer look.

    cheers,
      DaveK

RE: GCC4 status.

[Danny Smith]

Dave Korn wrote:
> Corinna Vinschen wrote:
> 
> > So why does it do that at all: "previous dllimport ignored"?
> > It shouldn't do that.  The dllimport should have precedence, IMHO.
> 
>   I don't know why it does that, it's just the behaviour of 
> vanilla upstream
> GCC.  I think it might be important, and have a vague memory 
> of some PR
> relating to this in the bugzilla.  I'll take a closer look.

It does that because native MS compiler does that as do/did other Windows compilers (I
think MSVC actually says "dllexport assumed").  The behaviour is due to a patch committed
in gcc 3.0 development but was also in the sources used by cygwin and mingw in 2.95.3
days.  There are several testsuite cases that expect this behaviour.

In olden (pre -funit-at-a-time) days it was critical because without the override
semantics we would sometimes get a function being used as a dllimport than later in the
same TU it would find a definition and the RTL generation would blow up. 
 
Danny

RE: GCC4 status.

[Danny Smith]

Charles Wilson
 
> Dave Korn wrote:
> > Corinna Vinschen wrote:
> >> #2)
> >>
> >>   
> 
> It's already on by default. The variable
> link_info.pei386_auto_import
> is currently initialized to -1, which means "Do it, but complain".
> 
> The only thing changing that initialization to "1" would do, 
> would be to
> stop complaining.

It also merges *all* .rdata variables into .data section. That's the pessimization.

Danny

Re: GCC4 status.

[Charles Wilson]

Danny Smith wrote:
> Charles Wilson
>> It's already on by default. The variable
>> link_info.pei386_auto_import
>> is currently initialized to -1, which means "Do it, but complain".
>>
>> The only thing changing that initialization to "1" would do, 
>> would be to
>> stop complaining.
> 
> It also merges *all* .rdata variables into .data section. That's the pessimization.

But

(a) implicitly enabled auto-import (-1) *doesn't* merge .rdata into
.data?  That seems...unwise.  I thought that the only way to keep .rdata
separate and non-writable was to --disable-auto-import.

(b) However, I also thought with Kai's runtime-pseudo-reloc-v2 changes,
at least, it is no longer necessary for fixuped references to be in a
writable page, so they can stay in .rdata? True/False?  ('Course, even
if true, this requires --enable-runtime-psuedo-relocs-v2 because only
-v1 is now the default for 32bit pe. And cygwin's runtime .o's don't yet
support -v2).

--
Chuck

Re: GCC4 status.

[Dave Korn]

Charles Wilson wrote:
> Danny Smith wrote:
>> Charles Wilson
>>> It's already on by default. The variable link_info.pei386_auto_import 
>>> is currently initialized to -1, which means "Do it, but complain".
>>> 
>>> The only thing changing that initialization to "1" would do, would be
>>> to stop complaining.
>> It also merges *all* .rdata variables into .data section. That's the
>> pessimization.

  I think we might have to live with it as a temporary measure, until we can
get the whole thing done with Kai's new relocs and even start to think about
disabling auto-import by default.

> But
> 
> (a) implicitly enabled auto-import (-1) *doesn't* merge .rdata into .data?
> That seems...unwise.  I thought that the only way to keep .rdata separate
> and non-writable was to --disable-auto-import.

  Nope, hence the warning.  Implicitly-enabled auto-import behaves as if
auto-import was disabled until it finds something that needs auto-importing,
then switches mode - but it's too late to reassign the sections, because the
linker script has already been selected by then.

    cheers,
      DaveK