Re: [MinGW-dvlpr] Yet another 3.4.5 release

[Danny S. <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.)

 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


>