[cfe-dev] "File too big/too many sections" when building Registry.cpp in MSYS2 Environment

[Reid Kleckner via cfe-dev]

On Sat, Dec 31, 2016 at 4:38 PM, William D. Jones <thor0505 at comcast.net>
wrote:

> 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.

On Sun, Jan 1, 2017 at 5:32 PM, William D. Jones <thor0505 at comcast.net>
wrote:

> 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20170103/23d0860f/attachment.html>