This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Toolchain relocation

Hash: SHA1

Dave Murphy wrote:
> Ranjit Mathew wrote:
>> However, when I moved the binaries to another machine
>> where MinGW was installed in "D:\MinGW", the compiler was
>> not able to find the C runtime headers, even though the
>> folder structure was exactly the same. 
> I think this is due to the compiler believing it was originally 
> installed at /mingw when in fact it was really installed at
> d:\MiscAppz\Mingw so the relocation of the include directory fails 
> because it can't relate the two.
> I'm still a little confused by this one because it would seem to 
> indicate that the paths to the binaries and libraries are relocated in a 
> different manner to the include directories since the relocated compiler 
> can find as, ld etc with no trouble.

GCC looks for an included header file in the following way:

> I know I experience the same problem if I don't configure with 
> --prefix=<drive>:/path/to. If I use mount points or the MSYS style 
> /<drive>/path/to then the newly built compiler can't find it's include 
> directories.

I am out of touch with MSYS/MinGW, but I seem to remember
that MSYS used to replace UNIX-y paths in the command-line like
"/mingw" with their correct mapping as given in /etc/fstab so
that applications get to the correct file when they use
things like fopen(), etc. which are provided directly by the
Windows C runtime (MSVCRT.dll) instead of an abstraction layer
as with Cygwin.

Note that since the other machine has MinGW in "D:\MinGW"
instead of "D:\MiscAppz\MinGW" as on the original machine,
even the above should not work for me.

>> There was another curious problem with this GCC, even on
>> the original machine where it was built: when run from within
>> the MSYS environment, everything was hunky-dory but when
>> run from the Windows command prompt, it used to give a
>> "_spawnvp: No such file or directory" error when one tried
>> to compile something.
> That's interesting. One of my end users reported a similar problem 
> recently but I've been unable to reproduce this locally under win2kpro. 
> Was this a win95/98 machine?

No, both the machines were running Windows 2000 Professional (SP4a).


- --
Ranjit Mathew       Email: rmathew AT gmail DOT com

Bangalore, INDIA.     Web:

Version: GnuPG v1.4.2 (GNU/Linux)
Comment: Using GnuPG with Mozilla -


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]