Kai Ruottu wrote:
Ranjit Mathew kirjoitti:
If I understand you correctly, you're saying that the
target runtime libraries are already created by the
cross-compiler in Phase 1, so I don't need to rebuild
them again in Phase 2 along with the crossed-native
compiler - I can get by by just building the compiler.
Yes, once being made and being thoroughly tested, any library shouldn't
be rebuilt. Doing that again only means a test for the compiler producing
the library - the result should by all sanity be identical in size and
bytes
with the existing...
Definitely the cross-GCC for the $target on the $build host is the
expected
compiler to produce the target libraries, not the new GCC being built for
the new $host and for the $target. In your case it could be possible
to have
Wine installed and then trying to run the new MinGW-hosted native GCC
on the $build host, but this isn't the assumption, the
$build-X-$target GCC
is the one producing the $target libraries, in your case the
'i686-mingw32-gcc'
(and all the stuff it uses as subprocesses, headers and libraries) or
something.
I don't know much about the internals of GCC, but what
you're saying should be possible though a bit cumbersome.
Building everything in Phase 2 (compiler and libraries)
just gives a nice bundle that I can then redeploy as I
wish (but this is precisely the thing that seems to be
broken, on MinGW at least).
I would go as far as not even producing that special "native GCC", but to
build instead a "MinGW-targeted and MinGW-hosted GCC" ! I have never
understood why the Windoze-host should cause the MinGW-targeted GCC
being in any way different from a Linux-hosted and MinGW-targeted GCC
in its install scheme... The MinGW-targeted GCC on Windoze really
doesn't
need to mimic any proprietary "native 'cc'" which has its headers in
'/usr/include'
and its libraries in '/usr/lib' or something.... Maybe some Unix
sources could
require the X11 stuff being in its "native" places, but never that the
C headers
and libraries would be in some virtual "native" places....
[snip]
All this is very interesting but has strayed quite a bit from the
problem at hand.
Something both Ranjit and I are experiencing is that relocation of a gcc
toolchain in the 4.x.x series is broken. The problem is especially
apparent on a windows host and symptoms vary depending on whether the
toolchain was built in a linux or a windows environment.
When a mingw gcc toolchain is built on a linux host then it cannot find
it's headers or it's associated tools when running from a cmd shell on
the windows host. This can be worked around by using the msys shell to
provide a mount point identical to the configured prefix but isn't ideal.
Any cross gcc built using mingw on a windows machine has problems when
the toolchain is relocated. The resulting toolchain here will always
attempt to access folders in the original configured directory which
results in a dialog asking the user to insert a disk when the original
install location is a removable media drive on the host machine.
Ranjit, the attached patch stops my cross toolchains accessing the
configured location when looking for specs files and tools but does not
yet address the include problem. In theory it should at least get your
linux built toolchains finding their tools when run on a windows host.
The problem with the include paths is that update_path in prefix.c
expects set_std_prefix to have been called with the location of the
relocated toolchain. While gcc does this, neither cc1 nor cc1plus do. I
think toplev.c needs some code to call make_relative_prefix and
set_std_prefix similar to gcc.c.
Dave
--- gcc-4.1.0/gcc/gcc.c Sat Jan 21 18:29:08 2006
+++ gcc-4.1.0-arm/gcc/gcc.c Mon Apr 24 16:05:45 2006
@@ -6148,10 +6148,10 @@
/* We need to check standard_exec_prefix/just_machine_suffix/specs
for any override of as, ld and libraries. */
- specs_file = alloca (strlen (standard_exec_prefix)
+ specs_file = alloca (strlen (gcc_exec_prefix)
+ strlen (just_machine_suffix) + sizeof ("specs"));
- strcpy (specs_file, standard_exec_prefix);
+ strcpy (specs_file, gcc_exec_prefix);
strcat (specs_file, just_machine_suffix);
strcat (specs_file, "specs");
if (access (specs_file, R_OK) == 0)
--- gcc-4.1.0/gcc/prefix.c Sat Jun 25 03:02:01 2005
+++ gcc-4.1.0-arm/gcc/prefix.c Tue Apr 18 05:03:53 2006
@@ -246,13 +246,16 @@
The returned string is always malloc-ed, and the caller is
responsible for freeing it. */
+
+static const char *old_prefix = PREFIX;
+
char *
update_path (const char *path, const char *key)
{
char *result, *p;
- const int len = strlen (std_prefix);
+ const int len = strlen (old_prefix);
- if (! strncmp (path, std_prefix, len)
+ if (! strncmp (path, old_prefix, len)
&& (IS_DIR_SEPARATOR(path[len])
|| path[len] == '\0')
&& key != 0)
