I suspect the slowness is due to the `clang` driver having to use the `gcc` driver to assemble and link. Perhaps MSYS's `sh` is also getting pulled into the party.
I build clang (Win7 32bit) from an svn checkout using a custom integrated MSYS/MinGW 4.6.2/autoconf toolchain like:
sh ../llvm-svn/configure --prefix=c:/clang --enable-optimized --disable-assertions \
--disable-docs --disable-pic --disable-pthreads --enable-targets=x86 \
--with-c-include-dirs=c:/DevKit/mingw/include --prefix=c:/clang
make
make install
# MinGW GCC 4.6.2
timer make
gcc -O2 -o w32time.exe -Wall w32time.c
...
real 0.608
system 0.093
user 0.000
# Clang 3.1 (trunk@r154095)
timer make CC=c:/clang/bin/clang.exe
c:/clang/bin/clang.exe -O2 -o w32time.exe -Wall w32time.c
...
real 5.101
system 0.046
user 0.000
Building './configure' based projects shows similar slowness.
Why is this, and what are the suggested workarounds?
FWIW, my clang advertises itself as posix thread model, and gcc advertises as win32 thread model. There is no `libwinpthread-1.dll` on PATH.
You could start by adding -v to see what it is actually invoking.
Of course. I used -v and -### so I could say "...the slowness is due to the `clang` driver having to use the `gcc` driver to assemble and link."
As a newcomer to the codebase, I'm not being critical of the current build performance. Far from it, I think it's incredible that it's so easy to build clang from svn _on_ windows; I understand about tradeoffs.
I'm looking to get more details as scanning the ML archives back to January and searching places like stackoverflow only go so far for understanding the current plans for clang+mingw on windows.
For example:
* what's the priority of clang+mingw wrt other clang tasks?
* what's the current plan to optimize? where should one start code spelunking?
* any different behavior planned for official 3.1?
* any of the core clang contributors interested enough to take lead on this issue?
* any hacky short-term workarounds to speed up builds using clang? (likely not)
* your build config looks OK, but you're doing threading support wrong; do ____.
* hey, this has already been discussed ad nauseum; go read post ???
How about adding LDFLAGS=-static (or similarly linking libstdc++ as static)?
Ok, I will look into that idea a bit later.
How long do you wait with "clang --help" ?
C:\Users\Jon>timer c:\clang\bin\clang.exe --help
OVERVIEW: clang "gcc-compatible" driver
...
real 2.229
system 1.950
user 0.000
C:\Users\Jon>timer c:\clang\bin\clang.exe --version
clang version 3.1 (trunk 154284)
Target: i686-pc-mingw32
Thread model: posix
real 1.947
system 1.950
user 0.000
C:\Users\Jon>timer gcc --help
Usage: gcc [options] file...
...
real 1.132
system 0.046
user 0.046
# MinGW GCC 4.6.2
timer make
...
real 0.592
system 0.078
user 0.000
# clang 3.1 (trunk 154297)
timer make CC=c:/clang/bin/clang.exe
c:/clang/bin/clang.exe -O2 -o w32time.exe -Wall w32time.c
...
real 0.594
system 0.046
user 0.031
And -v/-### shows clang still calling gcc in order to invoke as.exe and collect2.exe.
FWIW, this static clang+mingw also configured/built Ruby on Win7 in about the same time as MinGW 4.6.2.
I see clang/clang++ (~22.5MB not stripped) and clang.dll (~12.6MB) are roughly the same size as those not built with LDFLAGS=-static. What exactly did LDFLAGS=-static change?
Static clang is my new build configuration for experimenting. Any downsides or other tradeoffs I should be aware of?