Working on getting MingW32/native tools-only source build up

Hello, Kenneth

Using MingW32/GCC 4.2.1 binary release, mix of Cygwin and MingW32
auxilliary tools, ActivePerl's Perl 5.8.8; operating system Vista. I'm
not going to worry about bootstrapping llvm-gcc until I know I can
bootstrap gcc.

Don't do this. Use either pure cygwin or pure mingw (with msys + msysDTK)
installation. This will save bunch of time for you. Seriously.

1) ActivePerl uses the wrong shell (cmd.exe rather than sh.exe) when
doing backticks. I had to moderately rewrite llvm-config to use the Cwd
module's abs_path function before it worked.

See upper.

2) I'm getting massive link errors on template function instantiations
(no tools are being created), and won't have time to properly play with
this further "today". It looks like they're being stripped out
prematurely; I'll be checking the GCC documentation for how to prevent
this when I do have time.

Well. This can be gcc/binutils bug or something like this. I prefer to
be conservative and can declare, that everything is ok with gcc 3.4.5
and recent binutils available from mingw website.

Anton Korobeynikov wrote:

Hello, Kenneth

Using MingW32/GCC 4.2.1 binary release, mix of Cygwin and MingW32 auxilliary tools, ActivePerl's Perl 5.8.8; operating system Vista. I'm not going to worry about bootstrapping llvm-gcc until I know I can bootstrap gcc.
    

Don't do this. Use either pure cygwin or pure mingw (with msys + msysDTK) installation. This will save bunch of time for you. Seriously.
  

Actually, the only prebuilt things on this setup that are cygwin are bison 2.3 (recent MingW32 prebuilt bisons don't work, and I can't build-from-source past 1.75 thanks to unbypassable use of fork() ), m4 "just in case", and openssh.

Other than that and Perl, I am mostly using the leading-edge prebuilt binaries from the MingW32 website (including binutils). make and grep are locally built, and if I wasn't concerned about bison integration I could build m4 locally.

2) I'm getting massive link errors on template function instantiations (no tools are being created), and won't have time to properly play with this further "today". It looks like they're being stripped out prematurely; I'll be checking the GCC documentation for how to prevent this when I do have time.
    

Well. This can be gcc/binutils bug or something like this.

GCC docs have mentioned that you have to go through specific flags to prevent this. I just need to look up what those flags are, and check whether the *.o/*.a files are being stripped too aggressively.

Kenneth