Re: Fwd: GCC 3.1 linux-to-mingw32 near success but still some questions remain ;-)

["Kai Ruottu" <kai dot ruottu at luukku dot com>]

Pieter Thysebaert <pieter.thysebaert@intec.rug.ac.be> wrote:

> Ok, I've solved most problems myself:
> 
> 1) Only untarring the headers and mingw runtime in prefix/target
> is necessary  (not in prefix)

 This is the standard, the native Mingw with its '/mingw/include'
breaks all the rules... See '--with-local-prefix=...' in the GCC-install
manual, the words:

  "Indications are that people who use this option use it based on
   mistaken ideas of what it is for. People use it as if it specied where
   to install part of GCC. Perhaps they make this assumption
   because installing GCC creates the directory."

seem to be written just for the Mingw-people...

 However you may be wrong if you didn't install the w32api
headers anywhere... They are separate so my opinion is that
they should remain separate. There are two directories for target
headers with a cross-compiler, one for the 'Standard C headers'
(include) and another for 'System (specific) headers' (sys-include).
Just quess where the Win32-API headers should go...

 Please see with 'i386-mingw32-cpp -v'...

> 2) configure enabled long-long IO support....but strtoull and strtoll are 
> nowhere on my system, so re-doing the last step with --disable-long-long 
> worked fine!
>     Why is this not detected during the configure pass?

 Did you install the Mingw-patches for gcc-3.1.x ?  Don't remember any problems 
with these...

> 3) Why did I have to patch the ld/pe-dll.c file?

 The specific binutils sources you have are aimed for the single-eyed
'Windoze-host & Windoze-target' builds with 'msys', 'cygwin' etc., not
for generic builds on a Unix-compatible system with 'strncasecmp()'
(glibc or libiberty or something) instead of 'stricmp()'...

> 4) Using my fresh mingw32 cross compiler and binutils, I wanted to build 
> native mingw32 binutils and gcc.

 Please don't !  Much better would be to think the 'native' GCC being
a cross-GCC, then it would be identical with the Linux-hosted one...

 A command like :

.../configure --prefix=/temp/native-tools --build=i686-pc-linux-gnu \
--host=i686-pc-mingw32 --target=i586-pc-mingw32

would take care of that, because the host and target names differ...
After configuring you can edit the main 'Makefile' and change the
'target_alias' to the same as the 'host_alias' if you don't like the
'i586'...

 Also the idea about keeping the 'standard' and the 'system-specific'
headers in separate target-specific-header directories comes easier
with a cross-compiler... Or I haven't understood the aim for the non-
relative '/usr/local/i386-mingw32/include' versus the 'relative to the
$prefix' ('/mingw') stuff in the native toolchain...

 Ok, this only my opinion when not liking the arrangement in the
official Mingw-distribution... Besides I have tens of Mingw-hosted
GCCs and keeping the 'i386-mingw32' targeted similar to the others
(only one target more), not as a 'native' one with weird install
directories, simplifies things a lot...

> ../binutils.../configure --prefix=/temp/native-tools --host=i686-pc-mingw32 
> --target=i686-pc-mingw32 --build=i686-pc-linux-gnu
> make
> 
> Ends with an error because of conflicting type definitions in 
> libiberty/strerror.c and the mingw32 stdlib.h for "str_errorlist"

 Patching the '$build/libiberty/config.h' for something related to this,
is one possibility... When cross-building all those 'single-eyeness'
features in the GNU sources will arise... Believe me or not, but
RedHat seems to think that people prefer to use Cygwin when
building GNU stuff for Windoze, not their Linux... And the Mingw-
people think that everyone prefers Windoze with msys as the best
'Unix' for any builds... And these Windoze-nerds seem to rule the
GNU world now...

 Recently I have seen that people (or their companies) who have
paid big sums to MS for their NTs, 2k's and XPs, but paid nothing
to the free software community, e.g. by buying a Linux-distribution
and using it in the builds, seem to be very eager to demand 'no-cost'
consultation even on this list...

 If configuring on Windoze, the 'str_errorlist' probably would be found
ok with some dummy program run on the build host, but there aren't
enough 'known features for Mingw' integrated into the configure-scripts. Somehow 
the GNU-developers should be got to understand
that not everyone wanting to build tools for Windoze, wants to use
Windoze in the builds...  "If one wants to produce food for the flies,
one doesn't necessarily need to eat the same food..."

Cheers, Kai


------
Want more information?  See the CrossGCC FAQ, http://www.objsw.com/CrossGCC/
Want to unsubscribe? Send a note to crossgcc-unsubscribe@sources.redhat.com