CARPET driver creates errors - c++

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.

Related

Buildroot compile error - Maybe you need to increase the filesystem size (BR2_TARGET_ROOTFS_EXT2_SIZE)

Appreciate help if anyone have insight how to fix following compile error for buildroot that I have been struggling for almost a week.
I used following commands to pull buildroot repo and have tried this multiple times. I am using arm64 default config and before make enabling following flags
BR2_TARGET_ROOTFS_CPIO=y
BR2_TARGET_GENERIC_GETTY=y
BR2_TARGET_GENERIC_GETTY_PORT=”ttyAMA0″
After compile starts
git clone git://git.buildroot.net/buildroot
make qemu_aarch64_virt_defconfig
make
I see following error
mke2fs 1.46.3 (27-Jul-2021)
mkfs.ext4: No such file or directory while trying to determine filesystem size
*** Maybe you need to increase the filesystem size (BR2_TARGET_ROOTFS_EXT2_SIZE)
fs/ext2/ext2.mk:46: recipe for target '/home/jn4/linux-buildroot/buildroot/output/images/rootfs.ext2' failed
make[1]: *** [/home/jn4/linux-buildroot/buildroot/output/images/rootfs.ext2] Error 1
Makefile:84: recipe for target '_all' failed
make: *** [_all] Error 2
To change file system size I have tried modifying following parameter in .config file
BR2_TARGET_ROOTFS_EXT2_SIZE="250M"
I have tried many sizes - 60M, 120M, 250M, 256M, 512M, 1024M, however all have failed to compile with same error. This seems like a common problem with buildroot and there are few other posts in git or other places which recommends size of 250M to solve the problem. I continue to see compile error with many sizes I have tried.
Appreciate any insight since I am stuck at this point. Thank you.

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

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" ..

Compile z3 on Raspberry

Let me first of all apologize in case the question is unnecassary, but I am very new to modifiying compilers and cross architectural designs.
In order to evaluate the performance on various platforms I have been trying to compile the Z3 SMT solver on a raspberry pi 2. However there seems to be a problem due to the arm architecture. My intention so far was to use the configure script supplied by Mircrosoft Research, which works neatly and produces the following outcome:
Testing ar...
Testing g++...
Testing gcc...
Testing OpenMP...
Host platform: Linux
C++ Compiler: g++
C Compiler : gcc
Arithmetic: internal
OpenMP: True
Prefix: /usr
64-bit: False
Python version: 2.7
Writing build/Makefile
Copied Z3Py example 'example.py' to 'build'
Makefile was successfully generated.
python packages dir: /usr/lib/python2.7/dist-packages
compilation mode: Release
Type 'cd build; make' to build Z3
When building I first of all encouter the problem:
src/shell/install_tactic.cpp
cc1plus: error: unrecognized command line option '-mfpmath=sse'
cc1plus: error: unrecognized command line option 'u2018-msse'
cc1plus: error: unrecognized command line option 'u2018-msse2'
Makefile:3159: recipe for target 'shell/install_tactic.o' failed
make: *** [shell/install_tactic.o] Error 1
If I understood the meaning of this error correctly, these commad line options refer to clever tatics used to compute mathematical exercises and are not necessary if performance is not an issue. (Simply speaking, it should still work, even if it is slower).Removing the flags from the respective config.mk, allows building to a certain extend.
After sucessfully producing a lot of outcome files, the make process terminates with the following error:
src/util/hwf.cpp
../src/util/hwf.cpp:55:23: fatal error: emmintrin.h: Datei oder Verzeichnis nicht gefunden
compilation terminated.
Makefile:163: recipe for target 'util/hwf.o' failed
make: *** [util/hwf.o] Error 1
My question now is, whether it is again possible to compile without using emmintrin.h (simply copying the missing library to the Pi does not work, due to architectural hurdles). Has anyone ever done this?
Thank you in advance for all you helpful comments.
Both, the unsupported options and the error in hwf.cpp refer to the support for floating-point operations in Z3. The options are trying to make sure that the floating-point unit is set up correctly, and the error in hwf.cpp is because we're trying to get to hardware intrinsics for floating point operations. Essentially, the consequences of those changes are that some floating-point operations may be imprecise if those options are removed; however, not many pieces of Z3 rely on that, so it's unlikely you'll see errors later.
I do have a RPi at home, so I'll see whether we can use different options for that when I get home tonight. It may be that the RPi doesn't have a floating point unit at all though, in that case I'll have to switch it to soft floats (which we also have support for, but it may be slower).

make: *** [package/mac80211/compile] Error 1 in OpenWRT

I compiled my SDK several times and always I have the same result when I did make V=99, here are the errors that appear:
build_dir/linux-brcm47xx/compat-wireless-2011-05-27/drivers/net/wireless/b43/main.c:4240:3: error: implicit declaration of function 'ssb_commit_settings'
make[8]: *** [/home/rik/client/openwrt/build_dir/linux-brcm47xx/compat-wireless-2011-05-27/drivers/net/wireless/b43/main.o] Error 1
make[3]: Leaving directory `/home/rik/client/openwrt/package/mac80211'
make[2]: *** [package/mac80211/compile] Error 2
make[2]: Leaving directory `/home/rik/client/openwrt'
make[1]: *** [/home/rik/client/openwrt/staging_dir/target-mipsel_uClibc-0.9.32/stamp/.package_compile] Error 2
The answer for the first error can be found here: Why this "Implicit declaration of function 'X'"?
For the other part of the question ("I compiled my SDK several times and always I have the same result when I did make V = 99" and make[1][2][3] errors) you should keep in mind that if during the cross-compilation of the package you got an error, you first need to (obviously) get rid of the error in your source code (main.c in your case) and also (important!) go to /home/rik/client/openwrt/dl and delete [name_of_your_package].tar.gz. For some reason the toolchain fetches the source file ([name_of_your_package].tar.gz) only once and does not overwrite it if you run make package/[name]/compile V=99 even after you changed your source code. I.e. you need to delete that file manually. You got those errors because the toolchain was always trying to compile the very first source code you wrote and of course the result'd be always the same.
Simply put, the cross-compilation steps are as follows:
run make menuconfig and choose the desired package
run make package/[name]/compile
if(!) you got a compilation error, delete [name_of_your_package].tar.gz from /home/rik/client/openwrt/dl
correct the source code and repeat from step 1.
That is, every time gcc raises an error, you first need to delete the source fetched by the toolchain before trying to compile again.