Re: Crossed-Native Builds, Toolchain Relocation and MinGW
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Ross Ridge wrote: Ranjit Mathew wrote: In the problematic case, GCC is able to find cc1 but not as ... ... Note also that GCC's programme search path does not include its own location for some reason: ... d:/MiscAppz/MinGW/lib/gcc/i686-pc-mingw32/4.1.0/../../../../i686-pc-mingw32/bin/ This is the directory (i686-pc-mingw32/bin) where you should install the version of as.exe and ld.exe you want that installation of gcc to use. Thanks for pointing this out - I knew this, but for some reason it didn't strike me. What's happening is that I am using stock binutils binaries as distributed by the MinGW project, but compiling my own GCC binaries. The stock MinGW binutils (and GCC) are built for the target mingw32 (an alias for i386-pc-mingw32) while I was building for the target i686-pc-mingw32. So now I only need to figure out why the cross-compiler is not picking up headers from $PREFIX/$TARGET while building a crossed-native compiler, even though it used to do so in earlier releases. Thanks, Ranjit. - -- Ranjit Mathew Email: rmathew AT gmail DOT com Bangalore, INDIA.Web: http://rmathew.com/ -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2.2 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFETxdXYb1hx2wRS48RAl1mAJ9LGa+iqjfD3Om5WaiAynZd8O7iHACdHDHp Lf9WkRN3Qi0WYeAMlMjq66M= =MSnk -END PGP SIGNATURE-
Re: Crossed-Native Builds, Toolchain Relocation and MinGW
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Ranjit Mathew wrote: So now I only need to figure out why the cross-compiler is not picking up headers from $PREFIX/$TARGET while building a crossed-native compiler, even though it used to do so in earlier releases. This is misleading, so I think I should clarify. The problem is that I am building a crossed-native compiler for MinGW from Linux (i.e. build = i686-pc-linux-gnu, host == target = i686-pc-mingw32) using a just-built cross-compiler and the build fails on the stmp-fixinc Makefile target as it cannot find $SYSTEM_HEADER_DIR. After this patch: http://gcc.gnu.org/ml/gcc-patches/2005-08/msg00122.html $SYSTEM_HEADER_DIR is supposed to be /mingw/include for a native MinGW target (and since host == target, the build is being considered native). However, in a crossed- native build, I cannot have MinGW headers in this path, so the way I work around this problem is to additionally specify --with-sysroot=$PREFIX and extract MinGW headers into $PREFIX/mingw. This lets the build and installation complete successfully, but when I tar this installation and install it on a Windows machine, GCC fails to find the system headers. The workaround *then* is to rename the mingw folder to $TARGET (i.e. i686-pc-mingw32) again. Needless to say, this is painful. In earlier releases, I used to be able to just extract the headers to $PREFIX/$TARGET, do the crossed-native build, install the compiler and then bundle this installation up to create a relocatable toolchain. This was the whole point of the article: http://rmathew.com/articles/gcj/bldgcj.html I had written documenting this process. Note that in the follow-up message: http://gcc.gnu.org/ml/gcc-patches/2005-08/msg00142.html to the patch mentioned above, Danny Smith mentions that this patch causes no problems if MinGW is actually installed in /mingw. This seems to imply that the only $PREFIX that is properly supported is /mingw and the headers from mingw-runtime should be extracted into /mingw/include. Thanks, Ranjit. - -- Ranjit Mathew Email: rmathew AT gmail DOT com Bangalore, INDIA.Web: http://rmathew.com/ -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2.2 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFET27CYb1hx2wRS48RAna+AJ9NV06yXMi2tZSCppB1er3SXSrbYQCdEgV/ SBX3qobpH4eL3E+LF+ondX4= =XmbU -END PGP SIGNATURE-
Re: Crossed-Native Builds, Toolchain Relocation and MinGW
On Wed, Apr 26, 2006 at 06:29:46PM +0530, Ranjit Mathew wrote: $SYSTEM_HEADER_DIR is supposed to be /mingw/include for a native MinGW target (and since host == target, the build is being considered native). However, in a crossed- native build, I cannot have MinGW headers in this path, so the way I work around this problem is to additionally specify --with-sysroot=$PREFIX and extract MinGW headers into $PREFIX/mingw. This lets the build and installation complete successfully, but when I tar this installation and install it on a Windows machine, GCC fails to find the system headers. The workaround *then* is to rename the mingw folder to $TARGET (i.e. i686-pc-mingw32) again. Needless to say, this is painful. In earlier releases, I used to be able to just extract the headers to $PREFIX/$TARGET, do the crossed-native build, install the compiler and then bundle this installation up to create a relocatable toolchain. This was the whole point of the article: If you look at HEAD, you'll find a new --with-build-sysroot option. Does that help? We added it for some very similar configurations... -- Daniel Jacobowitz CodeSourcery
Re: Crossed-Native Builds, Toolchain Relocation and MinGW
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Daniel Jacobowitz wrote: On Wed, Apr 26, 2006 at 06:29:46PM +0530, Ranjit Mathew wrote: $SYSTEM_HEADER_DIR is supposed to be /mingw/include for a native MinGW target (and since host == target, the build is being considered native). However, in a crossed- native build, I cannot have MinGW headers in this path, so the way I work around this problem is to additionally specify --with-sysroot=$PREFIX and extract MinGW headers into $PREFIX/mingw. This lets the build and installation complete successfully, but when I tar this installation and install it on a Windows machine, GCC fails to find the system headers. The workaround *then* is to rename the mingw folder to $TARGET (i.e. i686-pc-mingw32) again. Needless to say, this is painful. In earlier releases, I used to be able to just extract the headers to $PREFIX/$TARGET, do the crossed-native build, install the compiler and then bundle this installation up to create a relocatable toolchain. This was the whole point of the article: If you look at HEAD, you'll find a new --with-build-sysroot option. Does that help? We added it for some very similar configurations... I found the documentation of the option in: http://gcc.gnu.org/install/configure.html a bit confusing and I had to actually look at Mark's original message: http://gcc.gnu.org/ml/gcc-patches/2005-07/msg01579.html to understand this option. That said, I was not able to come up with a description that is short *and* properly conveys the intention of the option. :-( Actually I still don't understand what libraries whose sysroot lives within the installation prefix (see Mark's message) means. Why does a library have a sysroot? Is this for doing something like -rpath? In any case, I don't readily see how --with-build-sysroot solves the particular problem I'm facing. Perhaps I'm missing something. What I want to be able to do is: 1. Create a folder and extract the C runtime headers and libraries into this folder (whether directly under it, or under $TARGET within it, or under mingw within it). 2. Configure and build binutils and GCC for MinGW using a cross-compiler and install them into the folder in #1. 3. Archive the folder and extract it on Windows boxen, possibly under different paths, and have GCC work properly without any changes. As I said, this *used* to be possible once upon a time. Thanks, Ranjit. - -- Ranjit Mathew Email: rmathew AT gmail DOT com Bangalore, INDIA. Web: http://rmathew.com/ -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFEUChgYb1hx2wRS48RAmw9AJ9hwGNKGvH22sZCP90EMtV3dVuITQCfUF0t UvWTg8YVxWoe0vHq45Sp4FY= =G5IW -END PGP SIGNATURE-
Re: Crossed-Native Builds, Toolchain Relocation and MinGW
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Dave Murphy wrote:
I'm totally at a loss to explain the problems Ranjit was experiencing in
this mail then.
http://gcc.gnu.org/ml/gcc/2006-04/msg00247.html
the part where he says 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.
The difference is that MSYS automatically adds the bin
folder of MinGW to the PATH. On the Windows command prompt,
I was trying to execute gcc directly without having its
bin folder in the PATH - if I add that folder to the PATH,
things work fine again. In the problematic case, GCC is able
to find cc1 but not as:
- --- 8 ---
E:\src\tmpd:\MiscAppz\MinGW\bin\gcc -v hello.c
Using built-in specs.
Target: i686-pc-mingw32
Configured with: ../gcc-4.1.0/configure --prefix=/mingw \
- --target=i686-pc-mingw32 --enable-languages=c,c++ \
- --disable-nls --disable-debug --enable-__cxa_atexit \
- --enable-threads=win32 --disable-win32-registry \
- --with-ld=/mingw/bin/ld.exe --with-as=/mingw/bin/as.exe
Thread model: win32
gcc version 4.1.0
d:/miscappz/mingw/bin/../libexec/gcc/i686-pc-mingw32/4.1.0/cc1.exe \
- -quiet -v -iprefix d:\miscappz\mingw\bin\../lib/gcc/i686-pc-mingw32/4.1.0/ \
hello.c -quiet -dumpbase hello.c -mtune=pentiumpro -auxbase hello \
- -version -o D:\TEMP/ccWC.s
ignoring nonexistent directory /mingw/include
ignoring nonexistent directory d:/MiscAppz/MinGW/i686-pc-mingw32/include
ignoring nonexistent directory /mingw/include
#include ... search starts here:
#include ... search starts here:
d:/miscappz/mingw/bin/../lib/gcc/i686-pc-mingw32/4.1.0/include
d:/MiscAppz/MinGW/include
d:/MiscAppz/MinGW/lib/gcc/i686-pc-mingw32/4.1.0/include
End of search list.
GNU C version 4.1.0 (i686-pc-mingw32)
compiled by GNU C version 4.1.0.
GGC heuristics: --param ggc-min-expand=64 --param ggc-min-heapsize=65462
Compiler executable checksum: ee311961bfecdede449f181caa4cf975
as -o D:\TEMP/ccI5.o D:\TEMP/ccWC.s
gcc: _spawnvp: No such file or directory
- --- 8 ---
(Long lines broken up manually.)
Note that I *had* specified --with-as, but I was using
UNIX-y paths which are *not* translated by MSYS for shell
scripts (unlike regular programmes):
- --- 8 ---
/e/src/tmp cat hello.c
#include stdio.h
int main( int argc, char *argv[])
{
if(argc 1)
printf( argv[1]: %s\n, argv[1]);
return 0;
}
/e/src/tmp gcc hello.c
/e/src/tmp ./a.exe /mingw
argv[1]: d:/MiscAppz/MinGW
/e/src/tmp cat scr.sh
#!/bin/sh
echo $*
/e/src/tmp ./scr.sh /mingw
/mingw
- --- 8 ---
Note also that GCC's programme search path does not include
its own location for some reason:
- --- 8 ---
d:/miscappz/mingw/bin/../libexec/gcc/i686-pc-mingw32/4.1.0/
d:/miscappz/mingw/bin/../libexec/gcc/
d:/MiscAppz/MinGW/libexec/gcc/i686-pc-mingw32/4.1.0/
d:/MiscAppz/MinGW/libexec/gcc/i686-pc-mingw32/4.1.0/
d:/MiscAppz/MinGW/libexec/gcc/i686-pc-mingw32/
d:/MiscAppz/MinGW/lib/gcc/i686-pc-mingw32/4.1.0/
d:/MiscAppz/MinGW/lib/gcc/i686-pc-mingw32/
/usr/libexec/gcc/i686-pc-mingw32/4.1.0/
/usr/libexec/gcc/i686-pc-mingw32/
/usr/lib/gcc/i686-pc-mingw32/4.1.0/
/usr/lib/gcc/i686-pc-mingw32/
d:/miscappz/mingw/bin/../lib/gcc/i686-pc-mingw32/4.1.0/../../../../i686-pc-mingw
32/bin/i686-pc-mingw32/4.1.0/
d:/miscappz/mingw/bin/../lib/gcc/i686-pc-mingw32/4.1.0/../../../../i686-pc-mingw
32/bin/
d:/MiscAppz/MinGW/lib/gcc/i686-pc-mingw32/4.1.0/../../../../i686-pc-mingw32/bin/
i686-pc-mingw32/4.1.0/
d:/MiscAppz/MinGW/lib/gcc/i686-pc-mingw32/4.1.0/../../../../i686-pc-mingw32/bin/
- --- 8 ---
This is the more readable version of the programs section
of the output of D:\MiscAppz\MinGW\bin\gcc -print-search-dirs.
See also PR bootstrap/22259:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22259
The curious thing is that I could not find the message
in gcc-patches corresponding to CGF's patch and I cannot
find out who defines USE_MINGW_MSYS.
In any case, all this has been overridden in mainline by
a series of patches from Jim Blandy and Mark Mitchell,
though I haven't bootstrapped GCC mainline on MSYS.
Thanks,
Ranjit.
- --
Ranjit Mathew Email: rmathew AT gmail DOT com
Bangalore, INDIA.Web: http://rmathew.com/
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.2.2 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFETdPEYb1hx2wRS48RAtDvAJwIFIHe8LQUsFWD8BJ5H4HWlk6i/gCfQbnM
S872RVKUETmoMikS+ymG+30=
=7rQb
-END PGP SIGNATURE-
Re: Crossed-Native Builds, Toolchain Relocation and MinGW
Ranjit Mathew wrote: In the problematic case, GCC is able to find cc1 but not as ... ... Note also that GCC's programme search path does not include its own location for some reason: ... d:/MiscAppz/MinGW/lib/gcc/i686-pc-mingw32/4.1.0/../../../../i686-pc-mingw32/bin/ This is the directory (i686-pc-mingw32/bin) where you should install the version of as.exe and ld.exe you want that installation of gcc to use. Ross Ridge
Re: Crossed-Native Builds, Toolchain Relocation and MinGW
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Kai Ruottu wrote: Because all the MinGW target libs already were produced during the step 1, it should sound being reinventing the wheel to try to reproduce these during the step 2 So one uses the 'make all-gcc', and gets only the GCC binaries for the new host. That there would be any problems in reproducing the extra libraries will remain totally unnoticed... 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. 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). Thanks, Ranjit. - -- Ranjit Mathew Email: rmathew AT gmail DOT com Bangalore, INDIA.Web: http://rmathew.com/ -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2.2 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFETHRVYb1hx2wRS48RAlCgAJsH3Vr2Ns2DkqXRb/QOzQsrzUaU+ACgiLE0 3IGHUaZ+230w3MP0Q4WfpqQ= =kyo9 -END PGP SIGNATURE-
Re: Crossed-Native Builds, Toolchain Relocation and MinGW
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
After one has 50 or so MinGW-hosted GCCs for all kind of targets, that
very weird native GCC has this far sounded being an oddball among all the
other GCCs using the cross GCC scheme... But this opinion of mine seems
to be opposite to the current trend: If one has 50 or so GCCs, each one of
them should use its own native install scheme on the cross-host, the new
--with-sysroot tries to enable this new bright idea
Anyway if even standardizing the $prefix for all the GCCs made by oneself,
for instance using the SVR4-like standard '/opt/gcc' as the $prefix,
one could
have quite identicallly installed GCCs on any host... Or the $prefix
could be
$host dependent, on Windoze/MinGW host for instance that '/mingw' being
the chosen $prefix for all the MinGW-hosted GCCs So when one has
only cross-GCCs everywhere and has only one standard $prefix in use
everywhere, copying becomes very easy. If one needs to copy the target
libs from '/opt/gcc/lib/gcc/i686-mingw32/3.4.6' on Linux onto just the same
place on Windoze, how this copying could be in any way cumbersome?
Ok, if the GCC configure command has for instance :
--build=i686-linux-gnu --host=i586-mingw32 --target=i686-mingw32
then the resulted GCC is a crosscompiler from 'i586-mingw32' to
'i686-mingw32'
because the $host is different from the $target And if the used
$prefix is the
same as used in the $build ('i686-linux-gnu' here) host, only the GCC
binaries
(the '.exe's for Windoze) would be different between the two MinGW-targeted
GCCs on Linux and Windoze hosts...
Generally it could be very informative to be capable to rebuild those
libraries on
more than one $build system using different $build-X-MinGW GCCs (but their
versions and the sources used to produce them being identical) and see
that the
results are really identical with identical GCC options being used in
compile. So
I really aren't against all reinventions, only thinking that using
just the same GCC
once again for the same task isn't that informative. But if you
really use the new
MinGW-hosted GCC for the rebuild on Linux using Wine, that could give some
new information about the quality of the new compiler...
Re: Crossed-Native Builds, Toolchain Relocation and MinGW
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)
Re: Crossed-Native Builds, Toolchain Relocation and MinGW
Dave Murphy wrote: 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. MinGW GCC is a native Win32 application and is unaffected by any mounts you create with MSYS. Ross Ridge
Re: Crossed-Native Builds, Toolchain Relocation and MinGW
Ross Ridge wrote: Dave Murphy wrote: 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. MinGW GCC is a native Win32 application and is unaffected by any mounts you create with MSYS It's affected when you run from the msys bash shell, my apologies for not being clear. Dave
Re: Crossed-Native Builds, Toolchain Relocation and MinGW
Ross Ridge wrote:
Ross Ridge wrote:
MinGW GCC is a native Win32 application and is unaffected by any mounts
you create with MSYS.
Dave Murphy wrote:
It's affected when you run from the msys bash shell, my apologies for
not being clear.
That makes no difference. MinGW GCC is a native Win32 application and
can't see any mounts you create with MSYS.
sorry but you're most definitely wrong about that.
[EMAIL PROTECTED] /e
$ cat /usr/local/test/test.c
#include stdio.h
int main(int argc, char **argv) {
printf(argv[0]);
return 0;
}
[EMAIL PROTECTED] /e
$ gcc -v
Reading specs from e:/MinGW/bin/../lib/gcc/mingw32/3.4.2/specs
Configured with: ../gcc/configure --with-gcc --with-gnu-ld --with-gnu-as
--host=mingw32 --target=mingw32 --prefix=/mingw --enable-threads
--disable-nls --enable-languages=c,c++,f77,ada,objc,java
--disable-win32-registry --disable-shared --enable-sjlj-exceptions
--enable-libgcj --disable-java-awt --without-x --enable-java-gc=boehm
--disable-libgcj-debug --enable-interpreter
--enable-hash-synchronization --enable-libstdcxx-debug
Thread model: win32
gcc version 3.4.2 (mingw-special)
[EMAIL PROTECTED] /e
$ gcc /usr/local/test/test.c -o /usr/local/test/test.exe
[EMAIL PROTECTED] /e
$ /usr/local/test/test.exe
E:\msys\local\test\test.exe
[EMAIL PROTECTED] /e
$
As you can see the paths are translated by the shell before being passed
to windows executables.
Dave
Re: Crossed-Native Builds, Toolchain Relocation and MinGW
Ross Ridge wrote: That makes no difference. MinGW GCC is a native Win32 application and can't see any mounts you create with MSYS. Dave Murphy wrote: sorry but you're most definitely wrong about that No, I'm not. The example you gave shows how MSYS mounts have an effect on the MSYS shell, which is not a native Win32 application. The toolchain relocation code in MinGW GCC is unaffected by MSYS mounts you might create, and so providing a mount point identical to the configured prefix won't have any effect. Ross Ridge
Re: Crossed-Native Builds, Toolchain Relocation and MinGW
Dave Murphy wrote: [EMAIL PROTECTED] /e $ gcc /usr/local/test/test.c -o /usr/local/test/test.exe [EMAIL PROTECTED] /e $ /usr/local/test/test.exe E:\msys\local\test\test.exe [EMAIL PROTECTED] /e $ As you can see the paths are translated by the shell before being passed to windows executables. No, you've actually just proved Ross' point correct. Gcc being a native win32 app gets the actual win32 path, not any kind of posix path that might be adjusted for MSYS mounts. If you took the above testcase and mounted /usr/local/test as /foobar and then ran /foobar/test.exe you would get identical output, E:\msys\local\test\test.exe, because that is the actual path to the binary. In other words, native win32 binaries are completely oblivious to any mounts created in MSYS, so using mounts is not a viable workaround since only MSYS apps will see a distinction. Brian
Re: Crossed-Native Builds, Toolchain Relocation and MinGW
Ross Ridge wrote: Ross Ridge wrote: That makes no difference. MinGW GCC is a native Win32 application and can't see any mounts you create with MSYS. Dave Murphy wrote: sorry but you're most definitely wrong about that No, I'm not. The example you gave shows how MSYS mounts have an effect on the MSYS shell, which is not a native Win32 application. The toolchain relocation code in MinGW GCC is unaffected by MSYS mounts you might create, and so providing a mount point identical to the configured prefix won't have any effect. oops, that'll teach me to think a bit more before posting :) I'm totally at a loss to explain the problems Ranjit was experiencing in this mail then. http://gcc.gnu.org/ml/gcc/2006-04/msg00247.html the part where he says 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. I can't say I've encountered that one locally but one of my users had this issue with win98. Dave
Crossed-Native Builds, Toolchain Relocation and MinGW
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hello, It seems that toolchain relocation, especially for crossed-native builds, seems to be broken in mainline while it used to work for earlier releases. The situation seems particularly bad for Windows (MinGW). I build GCC regularly only on Linux these days but in the distant past I used to build a GCJ for Windows using Linux for building a crossed-native compiler. This process is outlined in: http://rmathew.com/articles/gcj/bldgcj.html Now it does not seem to work as smoothly as it used to. First off, it seems that for MinGW the C runtime headers *must* be in /mingw/include (adjusting for sysroot): http://gcc.gnu.org/ml/java/2006-04/msg00056.html Earlier the compiler used to be able to pick up headers from $PREFIX/$TARGET, but now the $TARGET sub-folder must be renamed to mingw and --with-sysroot=$PREFIX needs to be specified. However, when the built crossed-native compiler is run on another (Windows) machine, the headers are not found by it and they seem to be picked up if $DIR/mingw is renamed back to $DIR/$TARGET. More seriously, this compiler is not able to find as from binutils, even though they are co-located in the same bin folder: http://gcc.gnu.org/ml/java/2006-04/msg00057.html This definitely used to work before. There also seem to be regressions in GCJ with the import of GNU Classpath as noted in the message linked to above, but fortunately that is easily overcome with a --with-gcj=$TARGET-gcj option. Thanks, Ranjit. - -- Ranjit Mathew Email: rmathew AT gmail DOT com Bangalore, INDIA. Web: http://rmathew.com/ -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFESQg9Yb1hx2wRS48RAmigAJ0TKr3bz3txfIRWL7za+eLlRu3qNQCeNdKT hlUOQbe37xDihTSzDdN1Clc= =prQu -END PGP SIGNATURE-
