Penalty of the MSVS compiler flag /bigobj

C++Visual StudioLinker Errors

C++ Problem Overview


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.

C++ Solutions


Solution 1 - C++

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.

Solution 2 - C++

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

Attributions

All content for this solution is sourced from the original question on Stackoverflow.

The content on this page is licensed under the Attribution-ShareAlike 4.0 International (CC BY-SA 4.0) license.

Content TypeOriginal AuthorOriginal Content on Stackoverflow
QuestionlrineauView Question on Stackoverflow
Solution 1 - C++Frédéric HamidiView Answer on Stackoverflow
Solution 2 - C++Conrad PoelmanView Answer on Stackoverflow