From: Danny S. <dan...@cl...> - 2008-03-30 01:16:35
|
> -----Original Message----- > From: min...@li... > [mailto:min...@li...] On Behalf > Of John E. / TDM > Sent: Saturday, 29 March 2008 1:48 p.m. > To: MinGW Devlopers Discussion List > Subject: Re: [MinGW-dvlpr] Yet another 3.4.5 release > > > Earnie Boyd wrote: > >> To see it, just run "gcc -print-search-dirs". Regardless > of where you've > >> placed the packages, in the Vista patched version, you'll see some > >> directories starting with "d:/JDevel/MinGW"; in the > original version, > >> you'll > >> see some directories starting with "/mingw". > >> > > > > I've always considered those as bogus and not required. I > suppose the > > heartbreak is that GCC actually tries to access D: and then either > > waits for a timeout or aborts. You should try to resolve the issue > > within the build of GCC not changing the environment it is built in; > > /mingw doesn't exist usually anyway and if it does it is > redundant with > > the other paths. > > Okay, I can come up with a patch for that. This has already been fixed in upstream sources. GCC driver detects if the standard relocateable paths exists. If they do, than it ignores the "hard-coded" -prefix=/config_path. As a fall back, it will then look for "well-known" paths ("/mingw/include" in case of mingw, "usr/include" for most everybody else.) I would still like > to use Cygwin > for building the new release, since the original release was, > after all, > built in Cygwin. (And since I've finally got all the problems > ironed out.) To use cygwin as build environemnt, I use "identify mounts" eg ... c:\develop on /develop type system (binmode) <<< this is root of source dirs and build dirs c:\mingw on /mingw type system (binmode) <<< this is where mingw gcc tree is insatlled in addition to the standard cygwin mounts Danny > |
From: John E. / T. <td...@td...> - 2008-03-30 02:45:59
|
Danny Smith wrote: > To use cygwin as build environemnt, I use "identify mounts" eg > ... > c:\develop on /develop type system (binmode) <<< this is root of source > dirs and build > dirs > c:\mingw on /mingw type system (binmode) <<< this is where mingw gcc tree > is insatlled > > in addition to the standard cygwin mounts Indeed. I'm glad you also pointed this out in an earlier message, or I might still have been wondering how to get it building under Cygwin. I've also had to patch Makefile.in to have it remove an extraneous CR on the end of the detected ld, create a wrapper script for ln to avoid Cygwin's soft links (I suspect there is a better way to do this), reenable the stub for convert_addresses() (did you instead omit the dependant Ada file in the library? I haven't really researched this one), and hack the libjava libtool because of a too-long command line. At any rate, I would like nothing more than to step back and let you or someone else more experienced provide a new 3.4.5 build; but if whatever reasons led to you step down from MinGW's GCC release manager position now prevent it, I'll muddle through myself. (Though at this point I'm finished with the muddling and am ready to package and upload.) -John E. |
From: Aaron W. L. <aar...@aa...> - 2008-03-30 05:01:15
|
John E. / TDM wrote: > At any rate, I would like nothing more than to step back and let you or > someone else more experienced provide a new 3.4.5 build; but if whatever > reasons led to you step down from MinGW's GCC release manager position now > prevent it, I'll muddle through myself. (Though at this point I'm finished > with the muddling and am ready to package and upload.) Is this Vista compatibility fix just a matter of rebuilding MinGW GCC with the -D__USE_MINGW_ACCESS flag? If so, I could do this if you like. |
From: John E. / T. <td...@td...> - 2008-03-30 18:49:54
|
Aaron W. LaFramboise wrote: > Is this Vista compatibility fix just a matter of rebuilding MinGW GCC > with the -D__USE_MINGW_ACCESS flag? > > If so, I could do this if you like. Yep, it's actually that simple. If you have the time and energy, by all means go ahead. The sooner the better, since there are at least a few outspoken users affected by either the Vista bug (i.e. they're running Vista and can't use the old packages) or the "hard-coded prefix bug" (i.e. they're using the new packages but drive 'D' is removable media). -John E. |
From: Aaron W. L. <aar...@aa...> - 2008-03-30 23:36:52
|
John E. / TDM wrote: > Aaron W. LaFramboise wrote: >> Is this Vista compatibility fix just a matter of rebuilding MinGW GCC >> with the -D__USE_MINGW_ACCESS flag? >> >> If so, I could do this if you like. > > Yep, it's actually that simple. If you have the time and energy, by all > means go ahead. The sooner the better, since there are at least a few > outspoken users affected by either the Vista bug (i.e. they're running Vista > and can't use the old packages) or the "hard-coded prefix bug" (i.e. they're > using the new packages but drive 'D' is removable media). OK, my timeline for a rebuild of 3.4.5 is an upload by Thursday evening. Right now my priority is a prerelease and roadmap for 4.3.0, and these builds are tying up my CPU time. If you can want to do it yourself sooner than that, by all means go for it. So should this release be 3.4.5-20060117-2 or 3.4.5-20060117-2-vista? I think the only risk of the former is that if I made a packaging mistake, it would impact our non-vista users who upgrade. Keith, Earnie, Chris, what do you think? |
From: Chris S. <ir0...@gm...> - 2008-04-01 15:58:49
|
Hey Aaron, Sorry for the delay... > So should this release be 3.4.5-20060117-2 or 3.4.5-20060117-2-vista? I > think the only risk of the former is that if I made a packaging mistake, > it would impact our non-vista users who upgrade. Keith, Earnie, Chris, > what do you think? My preference would be 3.4.5-20060117-2. Yes this build addresses the Vista issue, but it's not a vista only release, which is what I'm afraid a '-vista' name may infer. If there is a packaging bug hopefully it will be caught doing a comparison with the '-1' release in terms of tarball directory structure. Cheers! Chris -- Chris Sutcliffe http://emergedesktop.org |
From: John E. / T. <td...@td...> - 2008-04-06 19:37:16
|
Aaron W. LaFramboise wrote: > OK, my timeline for a rebuild of 3.4.5 is an upload by Thursday evening. > Right now my priority is a prerelease and roadmap for 4.3.0, and these > builds are tying up my CPU time. If you can want to do it yourself > sooner than that, by all means go for it. > For the sake of getting a non-regressive gcc 3.4.5 release for Vista users out the door, I'm uploading a set of 3.4.5-20060117-2 packages now. Because "Current Release: gcc-3.4.5" is already rather full, I'm going to rename it as "Previous Release: gcc-3.4.5-20060117-1" and create a new release for these packages entitled "Current Release: gcc-3.4.5-20060117-2". Hopefully there is no serious objection to this. -John E. |
From: Aaron G. <an...@be...> - 2008-04-06 22:51:20
|
> For the sake of getting a non-regressive gcc 3.4.5 release for Vista > users out the door, I'm uploading a set of 3.4.5-20060117-2 packages > now. Because "Current Release: gcc-3.4.5" is already rather full, I'm > going to rename it as "Previous Release: gcc-3.4.5-20060117-1" and > create a new release for these packages entitled "Current Release: > gcc-3.4.5-20060117-2". Hopefully there is no serious objection to this. Could you not use either the current date or a '-vista' suffix ? Aaron |
From: Charles W. <cwi...@us...> - 2008-04-06 22:56:46
|
Aaron Gray wrote: >> For the sake of getting a non-regressive gcc 3.4.5 release for Vista >> users out the door, I'm uploading a set of 3.4.5-20060117-2 packages >> now. Because "Current Release: gcc-3.4.5" is already rather full, I'm >> going to rename it as "Previous Release: gcc-3.4.5-20060117-1" and >> create a new release for these packages entitled "Current Release: >> gcc-3.4.5-20060117-2". Hopefully there is no serious objection to this. > > Could you not use either the current date or a '-vista' suffix ? I believe the date refers to the date of the source snapshot, not the build date. The -vista suffix is really a misnomer: this new gcc is not vista-ONLY, it is vista-CAPABLE. But there's no reason it can't be used on non-vista; in fact, it should probably be considered the official "latest" release of gcc-3.4.5 for mingw regardless of host OS. So there is no need to confuse folks with a -vista suffix. I think John E.'s proposal is the right way to go. -- Chuck |
From: Aaron G. <an...@be...> - 2008-04-06 22:52:56
|
>> For the sake of getting a non-regressive gcc 3.4.5 release for Vista >> users out the door, I'm uploading a set of 3.4.5-20060117-2 packages >> now. Because "Current Release: gcc-3.4.5" is already rather full, I'm >> going to rename it as "Previous Release: gcc-3.4.5-20060117-1" and >> create a new release for these packages entitled "Current Release: >> gcc-3.4.5-20060117-2". Hopefully there is no serious objection to this. > > Could you not use either the current date or a '-vista' suffix ? Sorry, missed the '-2' suffix, please ignore me. Aaron |
From: Aaron W. L. <aar...@aa...> - 2008-04-07 01:02:44
|
John E. / TDM wrote: > Because "Current Release: gcc-3.4.5" is already rather full, I'm > going to rename it as "Previous Release: gcc-3.4.5-20060117-1" and > create a new release for these packages entitled "Current Release: > gcc-3.4.5-20060117-2". Hopefully there is no serious objection to this. Sounds good. Thanks for doing this. (As you noticed, I was a little bit behind.) |
From: John E. / T. <td...@td...> - 2008-04-07 02:58:31
|
Aaron W. LaFramboise wrote: > John E. / TDM wrote: > >> Because "Current Release: gcc-3.4.5" is already rather full, I'm >> going to rename it as "Previous Release: gcc-3.4.5-20060117-1" and >> create a new release for these packages entitled "Current Release: >> gcc-3.4.5-20060117-2". Hopefully there is no serious objection to this. >> > > Sounds good. > > Thanks for doing this. > > (As you noticed, I was a little bit behind.) > No problem; I'd much rather have you working on getting usable 4.3 release in any case. -John E. |
From: Earnie B. <ea...@us...> - 2008-03-30 13:50:43
|
Quoting Danny Smith <dan...@cl...>: > > >> -----Original Message----- >> From: min...@li... >> [mailto:min...@li...] On Behalf >> Of John E. / TDM >> Sent: Saturday, 29 March 2008 1:48 p.m. >> To: MinGW Devlopers Discussion List >> Subject: Re: [MinGW-dvlpr] Yet another 3.4.5 release >> >> >> Earnie Boyd wrote: >> >> To see it, just run "gcc -print-search-dirs". Regardless >> of where you've >> >> placed the packages, in the Vista patched version, you'll see some >> >> directories starting with "d:/JDevel/MinGW"; in the >> original version, >> >> you'll >> >> see some directories starting with "/mingw". >> >> >> > >> > I've always considered those as bogus and not required. I >> suppose the >> > heartbreak is that GCC actually tries to access D: and then either >> > waits for a timeout or aborts. You should try to resolve the issue >> > within the build of GCC not changing the environment it is built in; >> > /mingw doesn't exist usually anyway and if it does it is >> redundant with >> > the other paths. >> >> Okay, I can come up with a patch for that. > > This has already been fixed in upstream sources. GCC driver detects > if the standard > relocateable paths > exists. If they do, than it ignores the "hard-coded" > -prefix=/config_path. As a fall > back, it will then look for "well-known" paths ("/mingw/include" in > case of mingw, > "usr/include" for most everybody else.) > Then I don't understand how the MSYS converted paths could matter. What is the exact result of having d:/JDevel/MinGW that should never be searched in the search paths? Earnie |
From: NightStrike <nig...@gm...> - 2008-03-30 16:07:52
|
On 3/30/08, Earnie Boyd <ea...@us...> wrote: > > Quoting Danny Smith <dan...@cl...>: > > > > > > >> -----Original Message----- > >> From: min...@li... > >> [mailto:min...@li...] On Behalf > >> Of John E. / TDM > >> Sent: Saturday, 29 March 2008 1:48 p.m. > >> To: MinGW Devlopers Discussion List > >> Subject: Re: [MinGW-dvlpr] Yet another 3.4.5 release > >> > >> > >> Earnie Boyd wrote: > >> >> To see it, just run "gcc -print-search-dirs". Regardless > >> of where you've > >> >> placed the packages, in the Vista patched version, you'll see some > >> >> directories starting with "d:/JDevel/MinGW"; in the > >> original version, > >> >> you'll > >> >> see some directories starting with "/mingw". > >> >> > >> > > >> > I've always considered those as bogus and not required. I > >> suppose the > >> > heartbreak is that GCC actually tries to access D: and then either > >> > waits for a timeout or aborts. You should try to resolve the issue > >> > within the build of GCC not changing the environment it is built in; > >> > /mingw doesn't exist usually anyway and if it does it is > >> redundant with > >> > the other paths. > >> > >> Okay, I can come up with a patch for that. > > > > This has already been fixed in upstream sources. GCC driver detects > > if the standard > > relocateable paths > > exists. If they do, than it ignores the "hard-coded" > > -prefix=/config_path. As a fall > > back, it will then look for "well-known" paths ("/mingw/include" in > > case of mingw, > > "usr/include" for most everybody else.) > > > > Then I don't understand how the MSYS converted paths could matter. > What is the exact result of having d:/JDevel/MinGW that should never be > searched in the search paths? It depends on whether or not (slim as the chance may be) that that path exists on the end user's system. |
From: Earnie B. <ea...@us...> - 2008-03-30 19:37:57
|
Quoting NightStrike <nig...@gm...>: > On 3/30/08, Earnie Boyd <ea...@us...> wrote: >> >> Quoting Danny Smith <dan...@cl...>: >> >> > >> > >> >> -----Original Message----- >> >> From: min...@li... >> >> [mailto:min...@li...] On Behalf >> >> Of John E. / TDM >> >> Sent: Saturday, 29 March 2008 1:48 p.m. >> >> To: MinGW Devlopers Discussion List >> >> Subject: Re: [MinGW-dvlpr] Yet another 3.4.5 release >> >> >> >> >> >> Earnie Boyd wrote: >> >> >> To see it, just run "gcc -print-search-dirs". Regardless >> >> of where you've >> >> >> placed the packages, in the Vista patched version, you'll see some >> >> >> directories starting with "d:/JDevel/MinGW"; in the >> >> original version, >> >> >> you'll >> >> >> see some directories starting with "/mingw". >> >> >> >> >> > >> >> > I've always considered those as bogus and not required. I >> >> suppose the >> >> > heartbreak is that GCC actually tries to access D: and then either >> >> > waits for a timeout or aborts. You should try to resolve the issue >> >> > within the build of GCC not changing the environment it is built in; >> >> > /mingw doesn't exist usually anyway and if it does it is >> >> redundant with >> >> > the other paths. >> >> >> >> Okay, I can come up with a patch for that. >> > >> > This has already been fixed in upstream sources. GCC driver detects >> > if the standard >> > relocateable paths >> > exists. If they do, than it ignores the "hard-coded" >> > -prefix=/config_path. As a fall >> > back, it will then look for "well-known" paths ("/mingw/include" in >> > case of mingw, >> > "usr/include" for most everybody else.) >> > >> >> Then I don't understand how the MSYS converted paths could matter. >> What is the exact result of having d:/JDevel/MinGW that should never be >> searched in the search paths? > > It depends on whether or not (slim as the chance may be) that that > path exists on the end user's system. > Based on what Danny stated, it shouldn't matter. If the path is never accessed by GCC why does it matter? Earnie |
From: John E. / T. <td...@td...> - 2008-03-30 20:44:59
|
Earnie Boyd wrote: >>> Then I don't understand how the MSYS converted paths could matter. >>> What is the exact result of having d:/JDevel/MinGW that should never be >>> searched in the search paths? >> >> It depends on whether or not (slim as the chance may be) that that >> path exists on the end user's system. >> > > Based on what Danny stated, it shouldn't matter. If the path is never > accessed by GCC why does it matter? It *is* accessed by GCC; that's the point. In the current GCC sources this doesn't happen because the original prefix is only checked as a fallback when the relative directories don't exist, but in 3.4.5 that fix isn't present -- so it searches on the D: drive and bam, people get an "insert disk into drive D:" error message. -John E. |