I moved the library files to my project, tried to build it and got this error.
Error - [Makefile.Debug:4179: debug/qcustomplot.o] Error 1
I moved the library files to my project, tried to build it and got this error.
Error - [Makefile.Debug:4179: debug/qcustomplot.o] Error 1
I've never seen this error, so just a few thoughts:
6.6.0 is a preview version of Qt, newer than the latest QCustomPlot (2.1.1), so possibly not compatible with 2.1.1. Have you tried a release version?
Is this a compile-time error or link time? Does the .o file exist and not zero bytes?
4179 looks like a line number - what does that line in the makefile say?
Qt 6.5.0 is out, and I think I'm now seeing the same error with MinGW. Relase build is ok, but debug build fails. On the Creator compile output tab, I see the error
as.exe: debug\qcustomplot.o: too many sections (32946)
To fix, add the following to your .pro file when using MinGW:
QMAKE_CXXFLAGS += -Wa,-mbig-obj
Ty!! It work.
Just a quick update to this thread for anyone facing issues with 2.1.1 and Qt 6.5.0. I'm also using MingGW, and the QMAKE_CXXFLAGS declaration didn't completely solve my build issues (both release and debug).
I've commented out the savePDF() components (which seemed to be the cause of the build errors) in the header and source files and now I can build without issue.
Never mind my above comment, it looks like I hadn't added printsupport to my .pro file!
Thank you!!!I also encounterd the same problem!!
This is a huge problem since it breaks portability. The compiler option is not recognized everywhere :(
It seems compiler/linker developers have reduced the ability of their tools to build larger object files, if not given according flags (like -mbig-obj).
So If you encounter this issue, I recommend first looking whether your compiler truly doesn't have this option; it might just be named differently.
If that doesn't help, you can also use QCustomPlot from the regular sources in the gitlab repo, instead of the two large amalgamated source files.
"It seems compiler/linker developers have reduced the ability of their tools to build larger object files, if not given according flags (like -mbig-obj)."
No, bigobj is a Windows specific issue. A Microsoft Windows Common Object File Format (COFF) file header by default only has a 16-bit NumberOfSections entry.
https://learn.microsoft.com/en-us/windows/win32/debug/pe-format
Code that produces object files that require more sections need to use an alternative format that has a 32-bit index. The alternative format makes the resultant object files somewhat larger, and makes them unable to be linked using the linker from Microsoft Visual Studio 2005 and earlier, but that's not a problem these days.
https://learn.microsoft.com/en-us/cpp/build/reference/bigobj-increase-number-of-sections-in-dot-obj-file
It has absolutely nothing to do with any compiler/linker developer "reducing the ability of their tools," but rather the latest code happens to now need more than 65,279 sections (it's not quite 2^16 for various reasons), so now the option must be added where it wasn't needed before.
Every compiler or linker that targets the Windows platform should have a method of enabling the larger object format, but as noted, the flag options might be different. (It's possible that somehow some linker doesn't, but I'd be doubtful.)
You don't have to worry about this if not compiling for Windows.