Using --with-sysroot and the location of system headers
Tue Sep 25 08:39:00 GMT 2007
> 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
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.
More information about the Gcc-help