-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
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
-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
-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
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
-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,
> everyth
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
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 wi
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, wh
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
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'
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 con
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 i
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
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.
Y
-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 "GC
Ranjit Mathew wrote :
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).
In this issue was something I didn't understand Let's ass
-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 Linu
18 matches
Mail list logo
