Re: Problem building binutils

["Kai Ruottu" <karuottu@freenet.hut.fi>]

On Thu, 1 Apr 1999 Michael Schwingen <rincewind@discworld.dascon.de> wrote :

> I just built some variants of egcs-1.1.2 on a CYGWIN (20.1) environment
> running on NT 4.0 - I did not have to convert anything, CYGWIN should take
> care of CR/LF (except when you have the disk mounted in binary mode - that
> will spoil the whole thing).
> 
> gcc compiled just fine, it failed somewhere in the multilib build process -
> when I took these out (I do not need them anyway - a config switch which
> turns all unnecessary libs off would be nice), everything worked fine.
> 
> (although I prefer building and using gcc under Unix - however, sometimes
> you can't choose ...)

 Sigh, this seems to be the FSF/Cygnus aim -- e.g. the recent gdb snapshots, 
make-3.77 and perhaps also some other GNU tools can be configured only under 
the 'native' Win32 environment (without any fixes to the 'configure' script). 
All kind of "This feature cannot be checked under a cross-development 
environment" errors will result from trying to configure e.g. with :  
--build=i486-linux --host=i386-cygwin32 (or 'i386-mingw32/i386-go32')

 Of course all this is bullshit, e.g. the make-3.77 configure cannot look from 
the header prototype if the DJGPP setvbuf() uses the 'old' order of parameters:
  int	setvbuf(FILE *_stream, int _mode, char *_buf, size_t _size);
instead of the 'new' order (which DJGPP 2.02 uses) :
  int	setvbuf(FILE *_stream, char *_buf, int _mode, size_t _size);
or have a 'if [($host=go32) || ($host=cygwin32) || ($host=mingw32)]' condition
for having data for some 'known systems' for which all tools may be built most
easily in a cross-development environment...

 Instead the configure script sees the only way to be to test things with a 
short program, run in the 'build/host' system...

 Of course all these things don't disable one from fixing the 'configure' and
giving it some known answers for DOS/go32, cygwin or mingw32 hosts, but anyhow
having these kind of things there is a nuisance and not having them could be 
much better... Perhaps these "features a'la MS" (it doesn't matter which 
system you use when you only have a MS-approved opsys...) should be reported
as bugs with fixes for them... Anyhow I still think that having only one piece
of sources under *nix is much better regarding maintainability and after fixing
the configure bugs, the whole build process is much easier... 

 If the building of GNU tools for DOS and Win32 hosts was too easy under 
Linux or any other *nix system, who then would think to use DOS, Win95 or 
NT for this same purpose? So perhaps there is some sense behind these 'bugs' 
--- to get more and more people converted to the beautiful DOS/Windoze world.

 As a run-time systems DOS/Win32 are Ok, the toolmakers don't need to use them 
for anything else but testing the resulted executables. But if all the 
toolmakers also must use them, perhaps it could be just better to forget these 
hosts... (unless someone thinks to pay something for making tools for them -- 
e.g. it's allowed to waste one's work time for these jobs...). I don't know how
the 'make.exe' was built for the DJGPP release, but being able to rebuild 
anything of these 'utilities' from sources for a DOS-hosted cross-toolset, if 
needed, and not needing to use DOS as the build environment, is what I 
prefer...

 Cheers, Kai
_______________________________________________
New CrossGCC FAQ: http://www.objsw.com/CrossGCC
_______________________________________________
To remove yourself from the crossgcc list, send
mail to crossgcc-request@cygnus.com with the
text 'unsubscribe' (without the quotes) in the
body of the message.