I'm (re)building a copy of Clang 3.9 for a git fork of LLVM (or1k) that tracks 3.9 but is not yet merged into LLVM proper. The last merge from the main Clang codebase was on Aug 11, release_39. When building, LLVM seems to compile fine. However, with Clang I am running into the following error as shown in this gist: llvm-err.txt · GitHub
Just to test, I have also confirmed that this same error occurs as of commit 54f5752c, release_39 branch, on the LLVM Github mirror. I have not tried HEAD of master, or SVN r290090 as of this writing. I also have not tried compiling an LLVM/Clang using MSVC, and am not currently in a position to try.
Are the above posts out of date, and the flag is now required? Are there any special options (besides overriding LDFLAGS directly) I may have forgot when generating the Makefiles? Building a Release build is not desirable for me for various reasons. My current LLVM/Clang, built in much the same way, is 3.5, so I know that in the past, too many sections wasn't an issue :).
The problem is particularly bad on Win64 because every C++ function gets
separate .pdata and .xdata sections, although I don't think GCC does
separate .debug_* sections for every inline function like MSVC. So, if you
get close to 2**16/3 or 21845 functions in one file, it's easy to pass this
limit. RecursiveASTVisitor uses CRTP, which makes it pretty easy to hit
this limit.
I'd add this flag to the llvm build myself, but my mingw64 build of clang
is currently broken for other reasons.
Not that I'm qualified to fix it, but... what's wrong with the build?
We should pass -mbig-obj so that users don't have to.
Sorry for the delay. I noticed that you pass the assembler options for only 64-bit builds. Is there any harm for enabling the flags for 32-bit builds as well? The 64-bit MinGW build appears to be broken on my machine (gcc 5.3.0); LTO.dll spent 30 minutes compiling before I manually disabled the build.
Did you cross-compile for MinGW? I've noticed that with the new change, native compile, Registry.cpp now compiles, but attempting to link
bin\clangDynamicASTMatchers.dll causes a link step that takes over 90 minutes (!!) before bombing with an excessive number of undefined symbols. So many, that I cannot even copy and paste them all from my scrollback. The linker cannot find any of the symbols from Registry.cpp.
It is dawning on me that building a Debug build of Clang/LLVM on Windows is impractical/development seems to mainly be done w/ gold on Linux to avoid linker woes.
2. Binutils do *not* support big-obj for 32-bit COFF target, thus it is *impossible* to debug build 32-bit hosted clang with GNU toolchain.
3. I believe, we should pay more attention to support self-hosted mingw-w64 clang, I maintain a couple of patches which allow me to build it, but I never tried to publish them, because I saw no interest. Btw, that recent LLVM patch introducing big-obj switch (https://github.com/llvm-mirror/llvm/commit/e1c9f504c6810be782714b8b39f11579e50fa5c7) also breaks self-hosted clang because gnu clang driver doesn't understand -Wa,-mbig-obj option. AFAIUI, LLVM handles COFF format automatically, selecting bigobj format if necessary, and msvc clang driver simply ignores '/bigobj' flag. I have a patch fixing gnu driver too.
Sorry for the delay. I noticed that you pass the assembler options for
only 64-bit builds. Is there any harm for enabling the flags for 32-bit
builds as well? The 64-bit MinGW build appears to be broken on my machine
(gcc 5.3.0); LTO.dll spent 30 minutes compiling before I manually disabled
the build.
32-bit builds don't create as many sections for every inline function as
64-bit builds do because they don't use .pdata and .xdata, so I was hoping
it was not needed.
Did you cross-compile for MinGW?
No. One day I'll try it, but today is not that day.
I've noticed that with the new change, native compile, Registry.cpp now
compiles, but attempting to link
bin\clangDynamicASTMatchers.dll causes a link step that takes over 90
minutes (!!) before bombing with an excessive number of undefined symbols.
So many, that I cannot even copy and paste them all from my scrollback. The
linker cannot find any of the symbols from Registry.cpp.
I also noticed it was very painful to link debug builds on Windows. I don't
think I actually attempted to link clang to confirm my fix, I only built
LLVM. I think it's slow for two reasons:
1. ld-bfd is really slow already, and slower when making PE files
2. DWARF symbols are impractically large
You can try building with less debug information (-g0) to speed things up.
If building with clang, you can use -gline-tables-only for the same purpose.
Anyway, I'll try linking clang to see if I can reproduce the Registry.cpp
link error.
It is dawning on me that building a Debug build of Clang/LLVM on Windows is
impractical/development seems to mainly be done w/ gold on Linux to avoid
linker woes.
The MSVC debug build is better supported, if that's an option for you.
I'm happy to review these kinds of patches if you want to CC me on them. I
don't have a lot of time to dedicate to mingw support in clang, so I mostly
apply other people's patches and confirm that things seem to work.
Accepting and ignoring the -mbig-obj flag in clang seems totally reasonable
to me. Our assembler should implicitly do the right thing, as you described.
Thanks for being so responsive. I've attached the patch. It happens in a different place than MSVC's one, since the MSVC has it's own CLCompatOptions.td, which GNU driver doesn't have.
