Re: GCC4 status.
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.
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.
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.
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.137r2=1.138cvsroot=srcf=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.
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/msg9.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.
-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.
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.
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.
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.
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.
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.
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.
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
Re: GCC4 status.
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.
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.
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.
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.
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.
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.
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.
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
GCC4 status.
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 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.
-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.
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.
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.
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.
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.
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.
-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-
