Fri 26 Feb 2016 07:35:35 PM UTC, comment #14:
That's not entirely accurate either. I am able to build without workaround on CentOS 6 with gcc 4.4 and Qt 4.6 because those were distributed and tested together.
There are always going to be odd corner cases that don't work for some people, we can't possible catch every single bad combination but we can capture most of them.
Better would be a test that would actually try to compile something with a Qt SIGNAL to trigger this specific error and flag it as an error, disable Qt, or maybe even automatically add the QT_NO_DEBUG option. That's not something I'm particularly motivated to work on, but please feel free to submit such a patch if you are.
|
Fri 26 Feb 2016 11:13:20 AM UTC, comment #13:
work around fine for me, however the configure script is now not accurate any more.
Should be something like this?
|
Fri 26 Feb 2016 05:35:35 AM UTC, comment #12:
That's great, workaround documented, I'm closing this as nothing to fix in Octave.
|
Thu 25 Feb 2016 10:14:38 PM UTC, comment #11:
yes, ../configure CPPFLAGS="-DQT_NO_DEBUG=1" <other options> works too.
|
Thu 25 Feb 2016 09:24:25 PM UTC, comment #10:
Thanks for looking into that workaround and posting. How about just adding -DQT_NO_DEBUG=1 to your user CPPFLAGS when building Octave? This can be done with
before calling configure, or on the configure command line
Does that work for you with no changes needed to Octave?
|
Thu 25 Feb 2016 09:00:35 PM UTC, comment #9:
The issue can also be fixed/worked around by adding
#define QT_NO_DEBUG 1 to config.h for QT versions < 4.8
This requires config.h to be included in 6 more files.
See attached diff_47215.txt
This works because the QLOCATION macros in qobjectdefs.h are conditional on QT_NO_DEBUG
(file #36464)
|
Tue 23 Feb 2016 07:41:01 PM UTC, comment #8:
I did a bit more digging, this is a Qt bug that has already been fixed.
See https://bugreports.qt.io/browse/QTBUG-22847
I am able to compile on CentOS 6 with gcc 4.4.7 (the version provided with the OS) and Qt 4.6.2 (the version of Qt provided with the OS, that still contains this bug as you are seeing). I can also build with a newer gcc and a newer Qt (that has fixed the bug).
So if you are going to build with gcc 4.7 or 4.9, you should probably correspondingly update your Qt to 4.8 (or patch your Qt headers). Either way this is not a bug in Octave.
|
Tue 23 Feb 2016 12:55:46 PM UTC, comment #7:
g++ 4.9.3 -std=gnu++11 on cygwin gives the same error message on the zz3.cpp/foo.cc snippet.
Without the -std=gnu++11 it compiles without error (both with g++ 4.9.3 on cygwin and g++ 4.7.3 on x86_64)
|
Tue 23 Feb 2016 07:28:45 AM UTC, comment #6:
On your snippet with the QTOSTRING_HELPER macro I get the same error message
g++ -std=gnu++11 zz3.cpp
zz3.cpp: In function 'int func(int)':
zz3.cpp:9:31: error: inconsistent user-defined literal suffixes '__FILE__' and 'QTOSTRING' in string literal
zz3.cpp:9:31: error: unable to find string literal operator 'operator"" _FILE_'
|
Tue 23 Feb 2016 07:23:31 AM UTC, comment #5:
cat /etc/redhat-release:
Red Hat Enterprise Linux Server release 6.7 (Santiago)
uname -m = x86_64
uname -r = 2.6.32-358.23.2.el6.x86_64
uname -s = Linux
uname -v = #1 SMP Sat Sep 14 05:32:37 EDT 2013
gcc (GCC) 4.7.3
qmake-qt4 -v
QMake version 2.01a
Using Qt version 4.6.2 in /usr/lib64
|
Mon 22 Feb 2016 08:42:34 PM UTC, comment #4:
With your example I do see a couple of warnings about string literal suffixes. My version of Qt has spaces between the tokens in QLOCATION, et al.
What OS, gcc version, and Qt version are you using? It's possible that introducing the -std=gnu++11 option to your version of gcc with your version of Qt is triggering these errors.
|
Mon 22 Feb 2016 08:38:44 PM UTC, comment #3:
You're missing a couple things in the example, where is QTOSTRING?
This snippet compiles cleanly for me:
All of these macros are from a standard installation of Qt, so this still points to something odd about your system libraries.
|
Mon 22 Feb 2016 08:30:00 PM UTC, comment #2:
building from a clean state does not help.
I'm near certain the build environment didn't change.
For the record: the error message can be reproduced with this,
where SIGNAL2 is a trimmed down version of SIGNAL macro
cat > yy.cpp <<HERE
#define QLOCATION "\0"__FILE__":"QTOSTRING(_LINE_)
// #define SIGNAL(a) qFlagLocation("2"#a QLOCATION)
#define SIGNAL2(a) ("2"#a QLOCATION)
#include <stdio.h>
int func(int a) {
fprintf(2, "%s", SIGNAL2(1));
}
HERE
g++ -c -std=gnu++11 yy.cpp
yy.cpp: In function 'int func(int)':
yy.cpp:7:19: error: inconsistent user-defined literal suffixes '__FILE__' and 'QTOSTRING' in string literal
yy.cpp:7:19: error: unable to find string literal operator 'operator"" _FILE_'
dusk.ad.intra{/scratch/aburgers/octave/x86_64 }223:
The QLOCATION and SIGNAL macros are picked up somewhere in the preprocessing stage during compilation of in this case libgui/qterminal/libqterminal/unix/Emulation.cpp
|
Sun 21 Feb 2016 11:11:52 PM UTC, comment #1:
Thanks for the report. The current default branch compiles fine on my system, can you make sure you are building from a clean state? If you still cannot build, can you bisect the change that is causing this error? Is it possible something else changed on your system to introduce this error?
|
Sun 21 Feb 2016 10:36:25 PM UTC, original submission:
since recently (say ~19-02-2016, didn't pin point the changeset yet) hg pulls fail to build on my system.
The lines and column numbers point to SIGNAL and SLOT.
libgui/src/color-picker.cc: In constructor 'color_picker::color_picker(QColor, QWidget*)':
libgui/src/color-picker.cc:40:18: error: inconsistent user-defined literal suffixes '__FILE__' and 'QTOSTRING' in string literal
libgui/src/color-picker.cc:40:18: error: unable to find string literal operator 'operator"" _FILE_'
libgui/src/color-picker.cc:40:39: error: inconsistent user-defined literal suffixes '__FILE__' and 'QTOSTRING' in string literal
libgui/src/color-picker.cc:40:39: error: unable to find string literal operator 'operator"" _FILE_'
|