65

The basic Google search bigobj issue shows that a lot of people are experiencing the Fatal Error C1128: "number of sections exceeded object file format limit : compile with /bigobj". The error has more chance to occur if one heavily uses a library of C++ templates, like Boost libraries or CGAL libraries.

That error is strange, because it gives the solution to itself: set the compiler flag /bigobj!

So here is my question: why is not that flag set by default? There must be a penalty of using that flag, otherwise it would be set by default. That penalty is not documented in MSDN. Does anybody have a clue?

I ask the question because I wonder if the configuration system of CGAL should not set /bigobj by default.

lrineau
  • 6,036
  • 3
  • 34
  • 47

2 Answers2

54

The documentation does mention an important drawback to /bigobj:

Linkers that shipped prior to Visual C++ 2005 cannot read .obj files that were produced with /bigobj.

So, setting this option by default would restrict the number of linkers that can consume the resulting object files. Better to activate it on a need-to basis.

Frédéric Hamidi
  • 258,201
  • 41
  • 486
  • 479
  • 2
    It feels to me like this is only part of the answer. Why does this problem not occur with gcc or clang? Do they have the behavior of something similar to `/bigobj` directly built in and _always-on_? – Ela782 Jan 14 '18 at 17:05
  • 2
    @Ela782, mingw have the same problem with big object files. Need to set `-Wa,-mbig-obj` in this case. Probably, gcc create smaller .obj or have a larger size limit. – mr NAE Feb 20 '19 at 08:05
  • Its the PE-COFF object file format which has a 16-bit index to the section table, rather than overall object size. The `/bigobj` option "kludges" this to a 32-bit index, but that wasn't supported pre-2005. GCC toolchain faces the same limitations, hence `-Wa,-mbigobj` - but may do optimization differently. On MSVC using string de-dup `/GF` (`/O1`, `/O2`) puts *each* string in its own section, which can dramatically increase section table size. – simon.watts Mar 12 '20 at 12:02
  • 17
    We're in 2020. 2005 is as far from today as 1990 was to 2005 when it was released. Did people in 2005 care about compatibility with MS-DOS 6-era linkers ? I pretty much doubt so. – Jean-Michaël Celerier Apr 18 '20 at 08:31
6

why is not that flag set by default? There must be a penalty of using that flag, otherwise it would be set by default.

My quick informal experiment shows .obj files to be about 2% larger with /bigobj than without. So it's a small penalty but it's not zero.

Someone submitted a feature request to make /bigobj the default; see https://developercommunity.visualstudio.com/t/Enable-bigobj-by-default/1031214.

Conrad Poelman
  • 822
  • 9
  • 11