Re: Using --with-sysroot and the location of system headers

1 msg	Making signaling nans signal?

Using --with-sysroot and the location of system...
\ NightStrike (24 Sep 2007)
. \ Brian Dessent (25 Sep 2007)

2 msg	Possible accepts invalid in C++: Thing::Thing::...
12 msg	Problems with building gcc 4.2.1
4 msg	force symbols for inline functions to be addres...
3 msg	undefined symbol
2 msg	error: forming reference to void
3 msg	GCC 4.2.1 build issue on Solaris 5.9 ?
11 msg	execution order
2 msg	gcc crosscompile for PPC, Please help!
3 msg	gcc compilation errors(c++)
3 msg	When to use if-if, else-if, switch, goto and lo...
5 msg	Re: Build on powerpc-ibm-aix4.3.1.0
3 msg	-ffast-math individual optimizations
1 msg	Cross toolchain problem.
4 msg	GCC ARM assembly questions
4 msg	is it possible to size a pointer's target?
2 msg	Passing temporary class instantiation as an arg...
1 msg	visibility and nested classes - im a bit confused
6 msg	local variable alignment on Solaris/SPARC, with...

Subject:	Re: Using --with-sysroot and the location of system headers
Group:	Gcc-help
From:	Brian Dessent
Date:	25 Sep 2007

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