|
From: Mojca M. <moj...@gm...> - 2015-12-09 10:41:26
|
Hi,
What other libraries for gnuplot (other than Qt and wxWidgets) need C++?
I'm facing some problems when trying to support gnuplot built against
Qt 5 on OS X < 10.9.
It starts with:
In file included from qtterminal/qt_term.cpp:78:
qtterminal/qt_conversion.cpp:129:9: error: use of undeclared
identifier 'isnan'; did you mean 'std::isnan'?
if (isnan(*image))
^~~~~
std::isnan
which I can fix by changing isnan to std::isnan, but the program
crashes anyway (on exit at least) if I don't compile it against libc++
(rather than libstdc++). I would like to know which other C++
libraries I would have to compile against libc++ if I want to compile
gnuplot against libc++.
Mojca
|
|
From: Hans-Bernhard B. <HBB...@t-...> - 2015-12-09 15:23:58
|
Am 09.12.2015 um 11:41 schrieb Mojca Miklavec: > What other libraries for gnuplot (other than Qt and wxWidgets) need C++? Basically none. > I'm facing some problems when trying to support gnuplot built against > Qt 5 on OS X < 10.9. That bodes trouble. I've seen various levels of incompatibility between clang and Qt5 for a while now (on Windows+Cygwin). > if (isnan(*image)) > ^~~~~ > std::isnan > > which I can fix by changing isnan to std::isnan, That one would be a simple enough fix. But there are more problems waiting to be found, including lots of unresolved reference into QString. > but the program crashes anyway (on exit at least) if I don't compile > it against libc++ (rather than libstdc++). Huh, don't remember having seen that name. What package does that library originate in? |
|
From: Mojca M. <moj...@gm...> - 2015-12-09 18:35:35
|
On 9 December 2015 at 16:23, Hans-Bernhard Bröker wrote: > Am 09.12.2015 um 11:41 schrieb Mojca Miklavec: > >> What other libraries for gnuplot (other than Qt and wxWidgets) need C++? > > > Basically none. > >> I'm facing some problems when trying to support gnuplot built against >> Qt 5 on OS X < 10.9. > > > That bodes trouble. I've seen various levels of incompatibility between > clang and Qt5 for a while now (on Windows+Cygwin). > >> if (isnan(*image)) >> ^~~~~ >> std::isnan >> >> which I can fix by changing isnan to std::isnan, > > > That one would be a simple enough fix. But there are more problems waiting > to be found, including lots of unresolved reference into QString. For me the rest worked out of the box. >> but the program crashes anyway (on exit at least) if I don't compile >> it against libc++ (rather than libstdc++). > > Huh, don't remember having seen that name. What package does that library > originate in? It's not from a package. It's a standard library that any C++ compiler links against. Mac OS X ships with both libstdc++ and libc++. Only libc++ supports C++11, but libstdc++ was the default before version 10.9. Mojca |
|
From: <pl...@pi...> - 2015-12-09 20:08:08
|
> It's not from a package. It's a standard library that any C++ compiler > links against. > > Mac OS X ships with both libstdc++ and libc++. Only libc++ supports > C++11, but libstdc++ was the default before version 10.9. > > Mojca > There is a compiler switch in gcc to force only stdc syntax, IIRC -std=c99 This should flush out any C11 specific code as errors. I think that is what you are trying to do. If that is not exactly what you need, you will probably find there is another switch to turn of C11 specifics that are not in your earlier libc++ Peter |
|
From: Hans-Bernhard B. <HBB...@t-...> - 2015-12-09 22:14:56
|
Am 09.12.2015 um 20:52 schrieb pl...@pi...: > There is a compiler switch in gcc to force only stdc syntax, IIRC > > -std=c99 > > This should flush out any C11 specific code as errors. I think that is > what you are trying to do. All fine and dandy, but completely irrelevant to the issue at hand, which deals with C++, not C. |
|
From: Hans-Bernhard B. <HBB...@t-...> - 2015-12-09 23:28:43
|
Am 09.12.2015 um 19:35 schrieb Mojca Miklavec: > On 9 December 2015 at 16:23, Hans-Bernhard Bröker wrote: >> But there are more problems waiting >> to be found, including lots of unresolved reference into QString. > > For me the rest worked out of the box. Interesting. This gave me reason to re-examine the root cause of these problems. Turns out that (at least on this platform), the only change needed to get it to build was adding "-fno-exceptions" to the CXXFLAGS. Now I'm stuck at the old "Could not connect to existing gnuplot_qt, starting a new one", and "Warning: slow font initialization" nuisance. But since that's the same between GCC and clang builds, I'll chalk that on up to Qt itself. >>> but the program crashes anyway (on exit at least) if I don't compile >>> it against libc++ (rather than libstdc++). "Crashes" is rather a small amount of information. Could you dig a little deeper, preferrably using the debugger? |
|
From: Mojca M. <moj...@gm...> - 2015-12-10 12:50:42
Attachments:
gnuplot.log.gz
|
On 10 December 2015 at 00:28, Hans-Bernhard Bröker wrote: > Am 09.12.2015 um 19:35 schrieb Mojca Miklavec: > >>>> but the program crashes anyway (on exit at least) if I don't compile >>>> it against libc++ (rather than libstdc++). > > "Crashes" is rather a small amount of information. Could you dig a little > deeper, preferrably using the debugger? I had a full stack trace, but I felt it was too long for the mailing list and discarded it. Now I tried to reproduce it and it no longer crashes, so I'm unable to send more information until I figure out what exactly triggers the crash. ... and then I remembered that crashes are logged. So I'm attaching it. But I don't know if anyone can make anything out of it except that maybe something was wrong with the thread management? Mojca |
|
From: Jun T. <tak...@kb...> - 2015-12-10 09:22:17
|
On 2015/12/09, at 19:41, Mojca Miklavec <moj...@gm...> wrote:
> qtterminal/qt_conversion.cpp:129:9: error: use of undeclared
> identifier 'isnan'; did you mean 'std::isnan'?
> if (isnan(*image))
> ^~~~~
> std::isnan
>
> which I can fix by changing isnan to std::isnan,
If I set
export CC=clang CXX=clang++
export CXXFLAGS='-std=c++11 -stdlib=libc++'
then I don't need to modify any source files (OS X 10.8, Qt5).
Do you get the isnan error even with this CXXFLAGS?
BTW, how did you install Qt5? I'm using the binary distribution
from http://www.qt.io/download-open-source/.
|
|
From: Mojca M. <moj...@gm...> - 2015-12-10 09:44:54
|
On 10 December 2015 at 09:40, Jun T. wrote: > On 2015/12/09, at 19:41, Mojca Miklavec wrote: >> qtterminal/qt_conversion.cpp:129:9: error: use of undeclared >> identifier 'isnan'; did you mean 'std::isnan'? >> if (isnan(*image)) >> ^~~~~ >> std::isnan >> >> which I can fix by changing isnan to std::isnan, > > If I set > export CC=clang CXX=clang++ > export CXXFLAGS='-std=c++11 -stdlib=libc++' > then I don't need to modify any source files (OS X 10.8, Qt5). > > Do you get the isnan error even with this CXXFLAGS? Probably not. I also don't get that error if I link against Qt 4. But if I use libc++ (which I might have to do eventually), I also need properly compiled wxWidgets (and hopefully nothing else). So I would like to understand whether I *need to* use libc++ or not. Most probably I will have to, but I'm not yet 100% sure. (Just to make it clear: I'm not trying to solve my own problem. I need to fix this inside a package manage that provides gnuplot, so it has to work for everyone.) The other question is whether adding "std::" prefix would break the functionality for someone else. > BTW, how did you install Qt5? With MacPorts. (And I have no alternative [other than maybe fixing Qt5 in MacPorts] because I'm packaging gnuplot for that.) Mojca |
|
From: Jun T. <tak...@kb...> - 2015-12-10 12:04:26
|
On 2015/12/10, at 18:44, Mojca Miklavec <moj...@gm...> wrote: > The other question is whether adding "std::" prefix would break the > functionality for someone else. If you add std:: then does it compile with Qt4? |
|
From: Mojca M. <moj...@gm...> - 2015-12-10 12:35:27
|
On 10 December 2015 at 13:04, Jun T. wrote: > On 2015/12/10, at 18:44, Mojca Miklavec wrote: > >> The other question is whether adding "std::" prefix would break the >> functionality for someone else. > > If you add std:: then does it compile with Qt4? Yes. It does for me. But I'm not claiming that it will continue to work everywhere (with every compiler on every platform). Google returns some relevant discussions: - https://gcc.gnu.org/bugzilla/show_bug.cgi?id=48891 - https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60407 - https://bugs.webkit.org/show_bug.cgi?id=59249 Mojca |