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: [RFU-1.7] astyle-1.23-1
On Feb 23 14:27, Chris Sutcliffe wrote: wget -x -nH --cut-dirs=1 \ http://emergedesktop.org/cygwin/astyle-1.23-1.tar.bz2 \ http://emergedesktop.org/cygwin/astyle-1.23-1-src.tar.bz2 Given the email from Corrina (I believe it was) a while back about ^^^ s/rrin/rinn/ influencing people to try the 1.7.0 release, I have not created any 1.5.x packages for this release (I don't have a 1.5.x install on my development box any more). Is this acceptable, or do I need to still create a 1.5.x release for this package? Nope. That's perfectly fine. Uploaded. Thanks, 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
