* GCC4 status. @ 2009-02-24 2:44 Dave Korn 2009-02-24 3:04 ` Dave Korn 2009-02-24 3:59 ` Yaakov (Cygwin/X) 0 siblings, 2 replies; 30+ messages in thread From: Dave Korn @ 2009-02-24 2:44 UTC (permalink / raw) To: cygwin-apps 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 ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: GCC4 status. 2009-02-24 2:44 GCC4 status Dave Korn @ 2009-02-24 3:04 ` Dave Korn 2009-02-24 3:59 ` Yaakov (Cygwin/X) 1 sibling, 0 replies; 30+ messages in thread From: Dave Korn @ 2009-02-24 3:04 UTC (permalink / raw) To: cygwin-apps 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 ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: GCC4 status. 2009-02-24 2:44 GCC4 status Dave Korn 2009-02-24 3:04 ` Dave Korn @ 2009-02-24 3:59 ` Yaakov (Cygwin/X) 2009-02-24 4:05 ` Dave Korn 1 sibling, 1 reply; 30+ messages in thread From: Yaakov (Cygwin/X) @ 2009-02-24 3:59 UTC (permalink / raw) To: cygwin-apps -----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----- ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: GCC4 status. 2009-02-24 3:59 ` Yaakov (Cygwin/X) @ 2009-02-24 4:05 ` Dave Korn 2009-02-24 5:05 ` Charles Wilson 0 siblings, 1 reply; 30+ messages in thread From: Dave Korn @ 2009-02-24 4:05 UTC (permalink / raw) To: cygwin-apps 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 ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: GCC4 status. 2009-02-24 4:05 ` Dave Korn @ 2009-02-24 5:05 ` Charles Wilson 2009-02-24 5:18 ` Christopher Faylor 2009-02-24 12:37 ` Dave Korn 0 siblings, 2 replies; 30+ messages in thread From: Charles Wilson @ 2009-02-24 5:05 UTC (permalink / raw) To: CygWin-Apps 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 ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: GCC4 status. 2009-02-24 5:05 ` Charles Wilson @ 2009-02-24 5:18 ` Christopher Faylor 2009-02-24 5:27 ` Charles Wilson 2009-02-24 12:37 ` Dave Korn 1 sibling, 1 reply; 30+ messages in thread From: Christopher Faylor @ 2009-02-24 5:18 UTC (permalink / raw) To: cygwin-apps 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 ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: GCC4 status. 2009-02-24 5:18 ` Christopher Faylor @ 2009-02-24 5:27 ` Charles Wilson 2009-02-24 5:51 ` Christopher Faylor 2009-02-24 9:15 ` Corinna Vinschen 0 siblings, 2 replies; 30+ messages in thread From: Charles Wilson @ 2009-02-24 5:27 UTC (permalink / raw) To: CygWin-Apps 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 ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: GCC4 status. 2009-02-24 5:27 ` Charles Wilson @ 2009-02-24 5:51 ` Christopher Faylor 2009-02-24 6:40 ` Yaakov (Cygwin/X) 2009-02-24 9:15 ` Corinna Vinschen 1 sibling, 1 reply; 30+ messages in thread From: Christopher Faylor @ 2009-02-24 5:51 UTC (permalink / raw) To: cygwin-apps 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 ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: GCC4 status. 2009-02-24 5:51 ` Christopher Faylor @ 2009-02-24 6:40 ` Yaakov (Cygwin/X) 0 siblings, 0 replies; 30+ messages in thread From: Yaakov (Cygwin/X) @ 2009-02-24 6:40 UTC (permalink / raw) To: cygwin-apps -----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----- ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: GCC4 status. 2009-02-24 5:27 ` Charles Wilson 2009-02-24 5:51 ` Christopher Faylor @ 2009-02-24 9:15 ` Corinna Vinschen 2009-02-24 16:35 ` Christopher Faylor 1 sibling, 1 reply; 30+ messages in thread From: Corinna Vinschen @ 2009-02-24 9:15 UTC (permalink / raw) To: cygwin-apps 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 ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: GCC4 status. 2009-02-24 9:15 ` Corinna Vinschen @ 2009-02-24 16:35 ` Christopher Faylor 2009-02-24 16:53 ` Corinna Vinschen 0 siblings, 1 reply; 30+ messages in thread From: Christopher Faylor @ 2009-02-24 16:35 UTC (permalink / raw) To: cygwin-apps 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 ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: GCC4 status. 2009-02-24 16:35 ` Christopher Faylor @ 2009-02-24 16:53 ` Corinna Vinschen 2009-02-24 18:13 ` Dave Korn 0 siblings, 1 reply; 30+ messages in thread From: Corinna Vinschen @ 2009-02-24 16:53 UTC (permalink / raw) To: cygwin-apps 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 ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: GCC4 status. 2009-02-24 16:53 ` Corinna Vinschen @ 2009-02-24 18:13 ` Dave Korn 2009-02-25 14:21 ` Corinna Vinschen 0 siblings, 1 reply; 30+ messages in thread From: Dave Korn @ 2009-02-24 18:13 UTC (permalink / raw) To: cygwin-apps 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 ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: GCC4 status. 2009-02-24 18:13 ` Dave Korn @ 2009-02-25 14:21 ` Corinna Vinschen 2009-02-25 17:21 ` Dave Korn 2009-02-26 3:29 ` Charles Wilson 0 siblings, 2 replies; 30+ messages in thread From: Corinna Vinschen @ 2009-02-25 14:21 UTC (permalink / raw) To: cygwin-apps 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 ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: GCC4 status. 2009-02-25 14:21 ` Corinna Vinschen @ 2009-02-25 17:21 ` Dave Korn 2009-02-25 17:37 ` Corinna Vinschen 2009-02-26 3:37 ` Charles Wilson 2009-02-26 3:29 ` Charles Wilson 1 sibling, 2 replies; 30+ messages in thread From: Dave Korn @ 2009-02-25 17:21 UTC (permalink / raw) To: cygwin-apps 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 ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: GCC4 status. 2009-02-25 17:21 ` Dave Korn @ 2009-02-25 17:37 ` Corinna Vinschen 2009-02-26 4:36 ` Dave Korn 2009-02-26 3:37 ` Charles Wilson 1 sibling, 1 reply; 30+ messages in thread From: Corinna Vinschen @ 2009-02-25 17:37 UTC (permalink / raw) To: cygwin-apps 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 ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: GCC4 status. 2009-02-25 17:37 ` Corinna Vinschen @ 2009-02-26 4:36 ` Dave Korn 2009-02-26 5:05 ` Danny Smith 0 siblings, 1 reply; 30+ messages in thread From: Dave Korn @ 2009-02-26 4:36 UTC (permalink / raw) To: cygwin-apps 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 ^ permalink raw reply [flat|nested] 30+ messages in thread
* RE: GCC4 status. 2009-02-26 4:36 ` Dave Korn @ 2009-02-26 5:05 ` Danny Smith 0 siblings, 0 replies; 30+ messages in thread From: Danny Smith @ 2009-02-26 5:05 UTC (permalink / raw) To: cygwin-apps 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 ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: GCC4 status. 2009-02-25 17:21 ` Dave Korn 2009-02-25 17:37 ` Corinna Vinschen @ 2009-02-26 3:37 ` Charles Wilson 2009-02-26 5:16 ` Danny Smith 1 sibling, 1 reply; 30+ messages in thread From: Charles Wilson @ 2009-02-26 3:37 UTC (permalink / raw) To: CygWin-Apps 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 ^ permalink raw reply [flat|nested] 30+ messages in thread
* RE: GCC4 status. 2009-02-26 3:37 ` Charles Wilson @ 2009-02-26 5:16 ` Danny Smith 2009-02-26 5:36 ` Charles Wilson 0 siblings, 1 reply; 30+ messages in thread From: Danny Smith @ 2009-02-26 5:16 UTC (permalink / raw) To: 'Mailing List: CygWin-Apps' 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 ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: GCC4 status. 2009-02-26 5:16 ` Danny Smith @ 2009-02-26 5:36 ` Charles Wilson 2009-02-26 5:58 ` Dave Korn 0 siblings, 1 reply; 30+ messages in thread From: Charles Wilson @ 2009-02-26 5:36 UTC (permalink / raw) To: CygWin-Apps 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 ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: GCC4 status. 2009-02-26 5:36 ` Charles Wilson @ 2009-02-26 5:58 ` Dave Korn 0 siblings, 0 replies; 30+ messages in thread From: Dave Korn @ 2009-02-26 5:58 UTC (permalink / raw) To: cygwin-apps 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 ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: GCC4 status. 2009-02-25 14:21 ` Corinna Vinschen 2009-02-25 17:21 ` Dave Korn @ 2009-02-26 3:29 ` Charles Wilson 2009-02-26 3:47 ` Yaakov (Cygwin/X) 1 sibling, 1 reply; 30+ messages in thread From: Charles Wilson @ 2009-02-26 3:29 UTC (permalink / raw) To: CygWin-Apps 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 ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: GCC4 status. 2009-02-26 3:29 ` Charles Wilson @ 2009-02-26 3:47 ` Yaakov (Cygwin/X) 2009-02-26 3:54 ` Charles Wilson 0 siblings, 1 reply; 30+ messages in thread From: Yaakov (Cygwin/X) @ 2009-02-26 3:47 UTC (permalink / raw) To: cygwin-apps -----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----- ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: GCC4 status. 2009-02-26 3:47 ` Yaakov (Cygwin/X) @ 2009-02-26 3:54 ` Charles Wilson 2009-02-26 4:23 ` Dave Korn 0 siblings, 1 reply; 30+ messages in thread From: Charles Wilson @ 2009-02-26 3:54 UTC (permalink / raw) To: CygWin-Apps 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 ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: GCC4 status. 2009-02-26 3:54 ` Charles Wilson @ 2009-02-26 4:23 ` Dave Korn 0 siblings, 0 replies; 30+ messages in thread From: Dave Korn @ 2009-02-26 4:23 UTC (permalink / raw) To: cygwin-apps 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 ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: GCC4 status. 2009-02-24 5:05 ` Charles Wilson 2009-02-24 5:18 ` Christopher Faylor @ 2009-02-24 12:37 ` Dave Korn 2009-02-24 14:29 ` Charles Wilson 1 sibling, 1 reply; 30+ messages in thread From: Dave Korn @ 2009-02-24 12:37 UTC (permalink / raw) To: cygwin-apps 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 ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: GCC4 status. 2009-02-24 12:37 ` Dave Korn @ 2009-02-24 14:29 ` Charles Wilson 2009-02-24 14:41 ` Dave Korn 2009-02-24 16:12 ` Christopher Faylor 0 siblings, 2 replies; 30+ messages in thread From: Charles Wilson @ 2009-02-24 14:29 UTC (permalink / raw) To: CygWin-Apps 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 ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: GCC4 status. 2009-02-24 14:29 ` Charles Wilson @ 2009-02-24 14:41 ` Dave Korn 2009-02-24 16:12 ` Christopher Faylor 1 sibling, 0 replies; 30+ messages in thread From: Dave Korn @ 2009-02-24 14:41 UTC (permalink / raw) To: cygwin-apps 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 ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: GCC4 status. 2009-02-24 14:29 ` Charles Wilson 2009-02-24 14:41 ` Dave Korn @ 2009-02-24 16:12 ` Christopher Faylor 1 sibling, 0 replies; 30+ messages in thread From: Christopher Faylor @ 2009-02-24 16:12 UTC (permalink / raw) To: cygwin-apps 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 ^ permalink raw reply [flat|nested] 30+ messages in thread
end of thread, other threads:[~2009-02-26 5:58 UTC | newest] Thread overview: 30+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2009-02-24 2:44 GCC4 status Dave Korn 2009-02-24 3:04 ` Dave Korn 2009-02-24 3:59 ` Yaakov (Cygwin/X) 2009-02-24 4:05 ` Dave Korn 2009-02-24 5:05 ` Charles Wilson 2009-02-24 5:18 ` Christopher Faylor 2009-02-24 5:27 ` Charles Wilson 2009-02-24 5:51 ` Christopher Faylor 2009-02-24 6:40 ` Yaakov (Cygwin/X) 2009-02-24 9:15 ` Corinna Vinschen 2009-02-24 16:35 ` Christopher Faylor 2009-02-24 16:53 ` Corinna Vinschen 2009-02-24 18:13 ` Dave Korn 2009-02-25 14:21 ` Corinna Vinschen 2009-02-25 17:21 ` Dave Korn 2009-02-25 17:37 ` Corinna Vinschen 2009-02-26 4:36 ` Dave Korn 2009-02-26 5:05 ` Danny Smith 2009-02-26 3:37 ` Charles Wilson 2009-02-26 5:16 ` Danny Smith 2009-02-26 5:36 ` Charles Wilson 2009-02-26 5:58 ` Dave Korn 2009-02-26 3:29 ` Charles Wilson 2009-02-26 3:47 ` Yaakov (Cygwin/X) 2009-02-26 3:54 ` Charles Wilson 2009-02-26 4:23 ` Dave Korn 2009-02-24 12:37 ` Dave Korn 2009-02-24 14:29 ` Charles Wilson 2009-02-24 14:41 ` Dave Korn 2009-02-24 16:12 ` Christopher Faylor
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).