Box include file unknown problem on gtkmm - c++

I'm working on a gtkmm3.0 app on Ubuntu and OSX.
I tried to make my project in three different enviroments:
OSx Big Sur
Ubuntu 16.04.7 LTS
Ubuntu 20.04.2 LTS
On the first and last one, my project is building well with no warnings and no errors, but in the second one, I'm having a bunch of exceptions(see below)
In file included from /usr/include/glibmm-2.4/glibmm/containerhandle_shared.h:25:0,
from /usr/include/glibmm-2.4/glibmm/object.h:34,
from /usr/include/pangomm-1.4/pangomm/context.h:32,
from /usr/include/gtkmm-3.0/gtkmm/widget.h:32,
from /usr/include/gtkmm-3.0/gtkmm/container.h:29,
from /usr/include/gtkmm-3.0/gtkmm/box.h:28,
from /home/workspace/CPPND-Linear-System-Solver/src/Gui.h:5,
from /home/workspace/CPPND-Linear-System-Solver/src/Gui.cpp:1:
/usr/include/glibmm-2.4/glibmm/variant.h:583:55: error: ISO C++1z does not allow dynamic exception specifications
tatic V_CastTo cast_dynamic(const VariantBase& v) throw(std::bad_cast);
^~~~~
/usr/include/glibmm-2.4/glibmm/variant.h:630:1: error: ISO C++1z does not allow dynamic exception specifications
throw(std::bad_cast)
^~~~~
/usr/include/glibmm-2.4/glibmm/variant.h:886:1: error: ISO C++1z does not allow dynamic exception specifications
throw(std::bad_cast);
^~~~~
/usr/include/glibmm-2.4/glibmm/variant.h:1069:1: error: ISO C++1z does not allow dynamic exception specifications
throw(std::bad_cast);
^~~~~
/usr/include/glibmm-2.4/glibmm/variant.h:1126:1: error: ISO C++1z does not allow dynamic exception specifications
throw(std::bad_cast);
^~~~~
CMakeFiles/linear_system.dir/build.make:75: recipe for target 'CMakeFiles/linear_system.dir/src/Gui.cpp.o' failed
make[2]: *** [CMakeFiles/linear_system.dir/src/Gui.cpp.o] Error 1
CMakeFiles/Makefile2:72: recipe for target 'CMakeFiles/linear_system.dir/all' failed
make[1]: *** [CMakeFiles/linear_system.dir/all] Error 2
Makefile:83: recipe for target 'all' failed
make: *** [all] Error 2
I'm googling since yesterday for a possible solution for it, and I did not found anything, but to define the throw which has not worked and seems to me its not a good practice. Also I looked for substitute the box container but besides it will give me so much work, it doesn't make sense to not work because of bad cast error just in one enviroment.
The exception happens on the line that I include the gtkmm/box.h file
and also I created a simple window application and it maked well, so as the exception message says, I think the problem is on the box.h file, but I didn't found a way to workaround it in Ubuntu 16.
App details:
C++17
gtkmm3.0
glib 2.4(in both ubuntu versions)
Installed all the gtkmm3.0 requirements previously the make, on https://www.gtkmm.org/en/download.html
Thank you

Related

CARPET driver creates errors

I am using Einstein toolkit on Windows via Cygwin.
When I use carpet driver, I have found errors because of HDF5 library.
I installed following packages;
curl,perl,subversion,git,gcc-{core,fortran,g++},make,patch,libjpeg-devel,openssl-devel,xgraph,vim.
It's working well with PUGH but CARPET is not working.
Kindly,tell me how I can fix it.
The errors:
/home/hp/cactus/configs/carpet/build/CarpetLib/limits.cc:
In function ‘void CarpetLib::set_system_limits()’:
/home/hp/cactus/configs/carpet/build/CarpetLib/limits.cc:27:13:
error: ‘RLIMIT_RSS’ was not declared in this scope set_limit(RLIMIT_RSS, "resident set size", max_memory_size_MB);
/home/hp/cactus/configs/carpet/build/CarpetLib/limits.cc:27:13:
note: suggested alternative: ‘RLIMIT_AS’ set_limit(RLIMIT_RSS, "resident set size", max_memory_size_MB);
Running configuration script for thorn MPI:
MPI selected, but MPI_DIR is not set.
Computing settings... Found MPI compiler wrapper at /usr/bin/mpic++! Successfully configured MPI.
Finished running configuration script for thorn MPI.
make[3]: *** [/home/hp/cactus/configs/carpet/config-data/make.config.rules:281: limits.cc.o] Error 1
make[2]: *** [/home/hp/cactus/lib/make/make.thornlib:113: make.checked] Error 2
make[1]: *** [/home/hp/cactus/lib/make/make.configuration:179: /home/hp/cactus/configs/carpet/lib/libthorn_CarpetLib.a] Error 2
make: *** [Makefile:263: carpet] Error 2
This was reported in 2013:
The warnings that are reported are harmless, since the content of the file does not matter -- what only matters is that there is at least one file generated when the self-test succeeds.
In general, scheduling a routine into a non-existing schedule bin means that this routine is not executed.
In many cases, this is just the right thing to do. In other cases, this is e.g. due to an error in schedule.ccl, which is why we moved from "silently not scheduling" to reporting warnings about these.
In this case, the warnings are harmless and no need to worry, since the thorns Boundary and SymBase are not actually required by CartGrid3D. One wishes there was a way to indicate this in the schedule.ccl so that these warnings could be omitted.
Regarding the use of CARPET, et the errors related to HDF5, here are all the current issues for the component CARPET with HDF5 in its description
A similar error was seen in this thread.
It illustrates that the error messages before the make/Error lines could help knowing what is going on.

fatal error while compiling pybind11 test cases on raspbian

Following this question, I'm now trying to compile the pybind11 test cases as instructed here on a Raspberry Pi. What I have done so far:
installed Raspbian Raspbian Buster Lite from the official page
updated/upgraded all packages
updated/upgraded python packages following the instructions here
compiled and installed pybind11 following the instructions here
my environment is:
Raspbian buster version 10
python 3.7.3
pip 20.0.2
gcc 8.3.0
Then running the command make check -j 4 the compiler stops at:
[ 68%] Building CXX object CmakeFiles/pybind11_tests.dir/test_numpy_dtypes.cpp.o
and the errors are:
c++: fatal error: Killed signal terminated program cplusplus
compilation terminated.
make[3]: *** [CMakeFiles/pybind11_tests.dir/build.make:297: CMakeFiles/pybind11_tests.dir/test_local_bindings.cpp.o] Error 1
make[3]: *** waiting for unfinished jobs...
make[2]: *** [CMakeFiles/Makefile2:110: CMakeFiles/pybind11_tests.dir/all] Error 2
make[1]: *** [CMakeFiles/Makefile2:191: CMakeFile/check.dir/rule] Error 2
make: *** [Makefile:157: check] Error 2
I would appreciate it if you could help me understand what is the problem and how I can solve it.
Doing more research and using the right keyword query, it seems this issue has nothing to do with bypynd11 or Raspbian for that matter. The issue seems to be with memory overflow as described in numerous posts before (including here and here). The solution might be to use fewer parallel processes -j <n> where n < 4, or do not use it at all as suggested here. For example, I tested the
make check -j 3
and it works. Or alternatively to create a swape file as described here.
Yes you have to create first swap file. After that you can do it. Acctually swap file will increase yor ram memory. It will use rom space for ram performance.
Please go through with below link it would help you.
https://youtu.be/Cr5mDFxvsb0

Coding error on BaseMacLayer

When building the Veins (Version:4.4) on Omnet version omnetpp-5.1pre2-src-windows, I get the following error output:
**19:58:05 **** Incremental Build of configuration gcc-release for project veins ****
make MODE=release all
make[1]: Entering directory '/c/Users/SIA/Omnet/omnetpp-5.1pre2-src-windows/omnetpp-5.1pre2/samples/veins/src'
veins/base/modules/BaseMacLayer.cc
veins/base/modules/BaseMacLayer.cc:74:29: error: cast from pointer to smaller type 'LAddress::L2Type' (aka 'long') loses information
myMacAddr = LAddress::L2Type(addressString.c_str());
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
1 error generated.
make[1]: *** [Makefile:165: ../out/clang-release/src/veins/base/modules/BaseMacLayer.o] Error 1
make[1]: Leaving directory '/c/Users/SIA/Omnet/omnetpp-5.1pre2-src-windows/omnetpp-5.1pre2/samples/veins/src'
make: *** [Makefile:12: all] Error 2
19:58:08 Build Finished (took 3s.360ms)**
Appreciate if someone can help me on this.
Though, admittedly, this also points to an underlying inconsistency in the code, Veins 4.4 is a simulation module library for OMNeT++ 4.6. It is also compatible with OMNeT++ 5.0.
You are using a version of OMNeT++ (5.1 pre-release) that Veins is not compatible with.
This means that a downgrade of your OMNeT++ installation should rectify the build error.
The Veins tutorial on http://veins.car2x.org/tutorial/ goes into more detail of which software needs to be installed (and how) for Veins to work.

Error when build Ogre on Linux: narrowing conversion

I am trying to get Ogre on Linux. I downloaded the source files and uncompressed them. Then I created the build folder then I ran "cmake ..". After that completed, I ran "make -j4" (I do have 4 cores and I have also tried just make). I get to 49% and it stops every time. I have downloaded the cmake gui and ran configure and checked all the boxes. I hit configure again and then generate. I tried running "make" again.
Downloads/ogre_src_v1-8-1/RenderSystems/GL/src/atifs/src/ps_‌​1_4.cpp:689:1: error: narrowing conversion of ‘-35051’ from ‘int’ to ‘uint {aka unsigned int}’ inside { } [-Wnarrowing] };
That is the error that pops up several times except they refer to a different line of the code in ps_1_4.cpp and the number ‘-35051’ is different.
Also, There are several warnings for casting the const GLboolean* to GLboolean* throughout the build but this is the message that I have at the end:
RenderSystems/GL/CMakeFiles/RenderSystem_GL.dir/build.make:542: recipe for target 'RenderSystems/GL/CMakeFiles/RenderSystem_GL.dir/__/__/RenderSystem_GL/compile_RenderSystem_GL_0.cpp.o' failed
make[2]: *** [RenderSystems/GL/CMakeFiles/RenderSystem_GL.dir/__/__/RenderSystem_GL/compile_RenderSystem_GL_0.cpp.o] Error 1
CMakeFiles/Makefile2:1057: recipe for target 'RenderSystems/GL/CMakeFiles/RenderSystem_GL.dir/all' failed
make[1]: *** [RenderSystems/GL/CMakeFiles/RenderSystem_GL.dir/all] Error 2
Makefile:160: recipe for target 'all' failed
make: *** [all] Error 2
Also every time that I have tried a new way I delete the build folder and start all over. Each time it appears to end with this message. I am still relatively new to Linux and CMake, so can you explain what is going on and how you came to this conclusion?
Note: I have found one forum that talks about this but I don't know where the build function is or how to change the CXX_FLAG.
Referenced post suggests that Ogre can be successfully built using gnu++98 standard (which is actually a c++98 plus GNU extensions).
The standard is set via compiler flags, in case of cmake flags may be passed as:
cmake -DCMAKE_CXX_FLAGS="--std=gnu++98" ..

Can't create QT postgresql plugin for Symbian device

I'm trying to create postgresql plugin for Symbian device but I can't compile it. I'm working on Windows 7 64bit.
I did everything according to this article: http://doc.qt.io/archives/qt-4.7/sql-driver.html#qpsql
C:\QtSDK\QtSources\4.8.1\src\plugins\sqldrivers\psql>qmake "INCLUDEPATH+=C:\Program Files (x86)\PostgreSQL\8.3\include" "LIBS+=C:\Program Files (x86)\PostgreSQL\8.3\lib\libpq.lib" psql.pro
WARNING: (internal):1: Unescaped backslashes are deprecated.
So, it looked OK. Then...
C:\...drivers\psql>C:\QtSDK\Symbian\tools\sbs\win32\mingw\bin\make debug-gcce
sbs -c arm.v5.udeb.gcce4_4_1
python.exe is not recognized as an internal or external command, operable program or batch file.
make: *** [debug-gcce] Error 9009
I noticed, that sbs_home was set to python directory but it was not in the path, then the make could not find the script raptor_start.py:
C:\...drivers\psql>echo %sbs_home%
C:\QtSDK\Symbian\tools\sbs\win32\python27
C:\...drivers\psql>set path=%path%;%sbs_home%
C:\...drivers\psql>C:\QtSDK\Symbian\tools\sbs\win32\mingw\bin\make debug-gcce
sbs -c arm.v5.udeb.gcce4_4_1
python.exe: can't open file C:\QtSDK\Symbian\tools\sbs\win32\python27\python\raptor_start.py': [Errno 2] No such file or directory
make: *** [debug-gcce] Error 2
C:\...drivers\psql>set sbs_home=C:\QtSDK\Symbian\tools\sbs
so, when I started compiling I got this error:
C:/QtSDK/Symbian/SDKs/Symbian3Qt474/epoc32/include/stdapis/stlportv5/stl/_istream.c:650: warning: suggest parentheses around '&&' within '||' target : epoc32\release\armv5\udeb\qsqlpsql.dll [arm.v5.udeb.gcce4_4_1]
FAILED linkandpostlink for arm.v5.udeb.gcce4_4_1: epoc32\release\armv5\udeb\qsqlpsql.dll
mmp: qsqlpsql_dll.mmp
c:/qtsdk/symbian/tools/gcce4/bin/../lib/gcc/arm-none-symbianelf/4.4.1/../../../../arm-none-symbianelf/bin/ld.exe: warning: C:/QtSDK/Symbian/SDKs/Symbian3Qt474/epoc32/release/armv5/udeb/usrt3_1.lib(ucppinit.o) uses variable-size enums yet the output is to use 32-bit enums; use of enum values across objects may fail
C:/QtSDK/Symbian/SDKs/Symbian3Qt474/epoc32/build/psql/c_8d95259b570e1766/qsqlpsql_dll/armv5/udeb/qsql_psql.o: In function `qMakeError': C:/QtSDK/QtSources/4.8.1/src/sql/drivers/psql/qsql_psql.cpp:175: undefined reference to `PQerrorMessage'
....many undefined references...
C:/QtSDK/QtSources/4.8.1/src/sql/drivers/psql/qsql_psql.cpp:117: undefined reference to `PQfreemem'
collect2: ld returned 1 exit status
mingw32-make[1]: *** [C:/QtSDK/Symbian/SDKs/Symbian3Qt474/epoc32/release/armv5/udeb/qsqlpsql.dll] Error 1
sbs: error: The make-engine exited with errors.
sbs : warnings: 3
sbs : errors: 2
built 'arm.v5.udeb.gcce4_4_1'
Run time 5 seconds
sbs: build log in C:\QtSDK\Symbian\SDKs\Symbian3Qt474\epoc32\build\Makefile.2012-06-26-15-03-12.78-2996.log
make: *** [debug-gcce] Error 1
Has anybody idea, what with it?
You are trying to build an Symbian/ARM application using precompiled binary postgresql client library for Windows. This won't ever work. The instructions you refer to only show how to build for OS X, Unix and Mac targets natively. You're cross compiling for Symbian.
You'd first need to obtain a binary version of the postgresql client library compiled for Symbian. It might exist out there, or you may need to compile it yourself. I don't think that the library supports Symbian as a target, and I couldn't readily find any Symbian ports for download. You may be out of luck for a trivial solution. A port might not be entirely out of the question, though -- perhaps the platform-specific code is localized enough.