Similar question with no real answer applicable to my case : CLICK
Question which I researched before asking here - CLICK
I'm using MinGW64 to try and compile a very large .cpp file (>13k lines), but I also have access to Visual Studio 2010 - if someone has a solution using that, feel free to tell me.
I've identified an error in the assembling stage -
... too many sections (33396)
C:\Users\username\AppData\Local\Temp\ccnAocvD.s: Assembler messages:
C:\Users\username\AppData\Local\Temp\ccnAocvD.s: Fatal error: can't write
CMakeFiles/source.dir/sourcecode.cpp.obj: File too big
I'm currently running the compilation with the -Os , --param ggc-min-expand=0, --param ggc-min-heapsize=4096 as suggested by two of my colleagues - the compilation is running way over 5 hours now.
Update:
As suggested by some people, I will just split the file into 2 source files and create a header for them - thanks.
Second Update:
Compilation hasn't finished yet(5 days !!!), even after creating a header and splitting the file into 4 smaller ones.
Final
This problem remained unresolved - even after following advice from everyone that posted I still couldn't manage to compile this.
Not sure about GCC, but have you tried the /bigobj flag for that specific file in VisualStudio?
I had the same issue with a large file, and it actually solved the issue. So it's worth a try.
From MSDN:
By default, an object file can hold up to 65,536 (2^16) addressable sections. This is the case no matter which target platform is specified. /bigobj increases that address capacity to 4,294,967,296 (2^32).
More about this here.
Related
I'm creating a project with openframeworks (the full source is here: https://github.com/morphogencc/ofxAsio/tree/master/example-udpreceiver), and the empty project seems to compile fine.
I added the ASIO library, and a few header classes, and now the project seems to be give me the following error:
1>------ Build started: Project: example-udpreceiver, Configuration: Debug x64 ------
1> main.cpp
1>cl : Command line error D8049: cannot execute 'C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\bin\x86_amd64\c1xx.dll': command line is too long to fit in debug record
1>cl : Command line error D8040: error creating or communicating with child process
I couldn't find any examples of error D8049 on stackoverflow or even on Microsoft's pages, and google turned up painfully few results. The only remotely useful one was this github issue:
https://github.com/deplinenoise/tundra/issues/270
But I'm still not sure what's causing the problem. Is anyone familiar with this error, and can recommend a method for troubleshooting what's causing it?
thanks in advance!
For me, working with UE4, this was an intermittent error.
I added "bLegacyPublicIncludePaths = false;" to the innermost block of project.Build.cs and recompiled without errors.
Then I removed that line and compiled again w/o errors.
The error message suggested adding "DefaultBuildSettings = BuildSettingsVersion.V2;" to project.Target.cs which worked.
This is a bit of a weird sounding error, as it is from essentially internally generated data. However, you do have control over that. Taking the error message at face value, you probably have many/lots of defined symbols passed in on the command line (or the the ones you do have have lengthy definitions), or you may have some lengthy file paths.
If you look under the project properties, one of the selections under the C++ section is "Command Line", which will show you exactly what gets passed to the compiler. When you view that you can see where you have many or lengthy parameters, and then make changes to shorten them.
Too many defines? Put them in a header (possibly stdafx.h) and include them that way.
Long file paths? Shorten the paths, put the files somewhere else, or set up file system aliases to your real directories that use shorter paths.
I have added some information to this question, below the line of xxxx.
I am attempting to move a large ActiveX (legacy) control from Visual C++ version 6 to Visual Studio 2010. The build went just fine under VSC++6. The automated conversion (within VS2010) seemed to run smoothly. There were a number of minor errors which had to be corrected in the code, such as having to declare variables to be integer rather than letting them default. Upon fixing the last error and building, the link step gave this error:
1>LINK : fatal error LNK1104: cannot open file '.\Debug\/.obj'
I have searched and found a couple people had asked about this problem, but the solutions were very project specific. I could find nothing that applied to my situation.
There were two projects in the original solution. To attempt to solve the problem, I separated them into two separate solutions, one of which produces a .dll and works and the other (to produce the activeX component) which fails with the above error.
I really don't know where to look.
I have no .cpp nor .h files with Debug in the filename.
There must be something telling the linker to look for this file... but where? How would I even recognize it. (I'm not even sure what the forward slash in the filename represents. Is it escaping the period... or does the pair of characters (backslash forwardslash, \ /) escape the forward slash meaning it is part of the filename?)
Where do I even start?
I think that I have heard that Visual Studio generates command lines which actually do the compilation and linking. Is there any way to see the generated command line to do the Link?
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
I just located 3 files with names and content as shown. They seem to be
related to the problem. The 3rd file shows the bad file name (twice). Can anyone tell me where in the Visual Studio GUI they are set up? Or what may cause the erroneous entries in the last file?
custombuild.command.1.tlog -------------------
^C:\DOCUMENTS AND SETTINGS\USER1\DESKTOP\QUILT00\QGETL32.ASM
..\Assembler\ml /Fo.\Debug\Qgetl32.obj /coff /I. /Zi /c /Cx /Ta Qgetl32.asm
^C:\DOCUMENTS AND SETTINGS\USER1\DESKTOP\QUILT00\ROT32.ASM
..\Assembler\ml /Fo.\Debug\Rot32.obj /coff /I. /Zi /c /Cx /Ta Rot32.asm
custombuild.read.1.tlog ----------------------
^C:\DOCUMENTS AND SETTINGS\USER1\DESKTOP\QUILT00\QGETL32.ASM
^C:\DOCUMENTS AND SETTINGS\USER1\DESKTOP\QUILT00\ROT32.ASM
custombuild.write.1.tlog ---------------------
^C:\DOCUMENTS AND SETTINGS\USER1\DESKTOP\QUILT00\QGETL32.ASM
C:\DOCUMENTS AND SETTINGS\USER1\DESKTOP\QUILT00\DEBUG\.OBJ
^C:\DOCUMENTS AND SETTINGS\USER1\DESKTOP\QUILT00\ROT32.ASM
C:\DOCUMENTS AND SETTINGS\USER1\DESKTOP\QUILT00\DEBUG\.OBJ
I was trying to compile exprtk.hpp file (https://exprtk.codeplex.com/) with mingw32(491_32) on Qt (win7).
During compilation, I give this error message:
debug\main.o:-1: error: too many sections (35325)
I've been noticed that the exprtk.hpp file is huge (>32000 lines).
I've been trying optimization flags on compiler but It didn't help eighter.
I'll be appreciated if somebody help me...
Regards,
You can by adding the compilation flags -flto -Wl,-allow-multiple-definition and you can add -fuse-linker-plugin
-Wa,-mbig-obj do not work on x86/32bits architecture (only x64)
Such huge header-only code is already bad design, i'd rather recommend to use another library, like muParser.
Your problem was already discussed in other threads, like this.
As you've already noticed, passing /bigobj to Microsoft's compiler
causes it to output a munged COFF format with up to 2^31 sections,
which "should be enough for anybody."
I've tested this new option with MinGW-w64 and it works. You need to
pass -Wa,-mbig-obj to gcc to opt-in to big objects (-Wa means pass
this option to the assembler). – Francis Gagné
This question already has answers here:
Closed 10 years ago.
Possible Duplicate:
gcc preprocessor output
For some reason I need to investigate some .i files generated by g++ preprocessor, where I see code like this:
#1 /usr/local/include/boost/python.hpp 1 3
#11 /usr/local/include/boost/python.hpp 3
I'm an experienced C++ programmer and I know what .i file is, the problem is, I can't find a detailed explanation on how to interpret the lines in .i file.
Can someone explain what the above lines mean (especially what the numbers following the files ) or point me a place where I can find some document about this?
Thanks, after looking at the link, my problem solved. I'd like to add some background in case somebody else see the same problem.
My project uses a strict compiler check, i.e., g++ -Wall -Werror. All warnings are treated as errors. And we are using boost.python, before yesterday, boost was put in /usr/local/include, and the compilation is fine. Then we decide to move boost into our source control for easier upgrade, and a warning (treated as error) arise.
So after the investigation and the details from the link given by CrazyCasta, the problem is actually this: when boost is in /usr/local/include, it is treated as a system header, so gcc supresses some warnings; while we move boost out, gcc is not that tolerable to it.
Basically, just ignore or supress that warning by hand.
Your answer can be found here.
Basically it's remapping the line number/filename space of the input so the compiler knows where lines came from. The first number is the line number of where the source came from, the filename after that is the file it came from. The numbers thereafter are flags.
I'm very new to C++; I've worked with several SDKs now on various applications and every time come across the problem that I can't get the 'example code' to compile. This is a very broad question basically regarding ANY example code that is given over the net - what is the standard procedure to make things compile? I know how to compile code that I've written myself but when given a large project containing several CPP and H files, what do I start with? My first port of call, to open 'main.cpp' in Dev-C++ and hit the 'compile' button generally throws up errors about header files not being available and so on.
I won't give a specific example as this has happened several times. I feel as someone getting to grips with C++ that I would learn a lot quicker if I could start with code that works and tweak it myself rather than having to fumble around building things up piece by piece.
The most recent example is a set of example code provided by a company which 10 files:
-Arial.ttf
-demo_resources.rc
-icon.ico
-main.c
-simple.dsp
-simple.dsw
-simple.exe
-simple.h
-trial.c
-trials.c
Running the .exe file works absolutely fine; however if I open main.c and press compile, I receive many error messages. As an example, the first two lines of code in main.c are:
#include "simple.h"
#include <sdl_text_support.h>
This alone spews the error messages:
1: expected unqualified-id before "public"
1: expected `,' or `;' before "public"
2: In file included from trial.c
Clearly I am doing something very wrong as this code must have compiled for someone else in the past to have generated the .exe file. Again this is not an isolated issue, I have this problem all the time.
Since Dev-C++ is perfectly equipped to deal with plain old C files, I can't see that that is the issue. Secondly, simple.h is definitely included in the correct directory. The second include though, sdl_text_support.h is obviously not in my file list above. I have searched the rest of the SDK and found the file lurking elsewhere. How do I explicitly reference the location of the header file using Dev-C++?
Any general tutorial to how to compile pre-made projects or help of any kind would be greatly appreciated.
I like this page:
http://www.cprogramming.com/tutorial.html
I am not familiar with DevC++, but you cannot assume that if you can open main.c and press a button, then everything will work out. No build system is that smart.
If you write your own code (and you understand compiling and linking) then you can keep your files in order and know exactly how to build everything; someone else's codebase may come with a makefile or some other guide to it's organization, but you'll have to learn how to use a good build system, and the one you're using sounds inadequate.
open the project by simple.dsw instead of main.cpp and it should work .