NightStrike wrote: > Why is this? Because /mingw/include is the location for system includes for the MinGW target, by definition. There's no such thing as a "/usr" on Windows, so why would it look there? The "/mingw" prefix is kind of a placeholder that means the root of the tree where the binaries were installed, whereever that may be. The expectation of Windows programs is that the user can arbitrarily choose where they are installed. gcc accomplishes this by locating paths (e.g. for include headers and subprograms like cc1) at runtime by using relocation code that turns absolute paths into relative paths. This means that as long as you unpack the whole toolchain (gcc, binutils, w32api, mingw-runtime) into the same dir, you can locate that dir anywhere you want and everything should work. But for the purposes of configuring and building gcc some kind of name is still needed for that location, so there is this /mingw placeholder. [ And also, as far as I know, this means that when building MinGW gcc native you must always specify --prefix=/mingw if you want the result to be relocatable so that at runtime the relocation code will recognise the paths /mingw/include and /mingw/lib for what they are and turn them into paths relative to the location where the gcc binary is located. ] For the rest of the MSYS programs, the /etc/fstab file must be updated to set /mingw to the actual location where the tools have been installed (unless of course this location is a dir named "mingw" under the MSYS root, in which case no translation is needed.) This provides consistency across all tools that /mingw means the root dir where MinGW was installed. Now all of the above is in the context of the native tools, so of course it's going to be a little different when you're using a cross, especially since the whole point of a sysroot is that it overrides all that relocation logic and just flat out specifies a location. Brian
