Coding error on BaseMacLayer - c++

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.

Related

Error using Cygwin: "collect2: fatal error: ld terminated with signal 11 [Segmentation fault]"

I'm trying to use cygwin to download openslide (building natively on Windows) on a Windows 10 x64 system. I ran into an error earlier relating to chk_fail and set the line in the build file with -D_FORTIFY_SOURCE to 0 instead of the default (2). You can probably tell by now I don't really know what I'm doing. But I got a new error below relating to a memory error from what I've read. I tried deleting the whole package folder including the makefiles and object files, then clone from Github again and rebuild, but it didn't work. Can anyone give me pointers about what's happening here and how to fix it? It would be much appreciated.
Scanning dependencies of target ziptool
[ 90%] Building C object src/CMakeFiles/ziptool.dir/ziptool.c.obj
[ 90%] Linking C executable ziptool.exe
collect2: fatal error: ld terminated with signal 11 [Segmentation fault], core dumped
compilation terminated.
make[2]: *** [src/CMakeFiles/ziptool.dir/build.make:109: src/ziptool.exe] Error 1
make[2]: *** Deleting file 'src/ziptool.exe'
make[1]: *** [CMakeFiles/Makefile2:442: src/CMakeFiles/ziptool.dir/all] Error 2
make: *** [Makefile:161: all] Error 2
Failed: make $parallel (line 417)
I solved this problem. Firstly, don't even bother to build this package using Cygwin. It won't work because of dependency issues and there is no record for version control in the package README.
For anyone else who has this problem like I did, you can download the latest versions of the code here: https://github.com/openslide/openslide-winbuild/releases and pick the latest one.
I first pip installed openslide-python. Then I moved openslide-win64-20171122 (from Github) into anaconda3/site-packages (not necessary, but nice), and then from anaconda3/site-packages/openslide I opened lowlevel.py.
In lowlevel.py, you need to add the following lines:
(in the beginning after importing libraries)
os.environ['PATH'] = "path/to/openslide-win64-20171122/bin" + ";" + os.environ['PATH']
You can also change this line:
if platform.system() == 'Windows':
_lib = cdll.LoadLibrary('libopenslide-0.dll')
to this:
if platform.system() == 'Windows':
_lib = cdll.LoadLibrary(util.find_library("libopenslide-0.dll"))
so that it searches for the libopenslide-0.dll file. Then don't forget to add from ctypes import util at the beginning.

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

Linux From Scratch error in Bison-3.0.4 'make check'

So I'm following the Linux From Scratch book and am in chapter 5.17 Bison-3.0.4.
The book instructs us to do a make check after make to test the result of the compiled Bison package.
Initially, I was getting the following error:
make[3]: Entering directory `/sources/bison-3.0'
LEX examples/calc++/calc++-scanner.cc
CXX
examples/calc++/examples_calc___calc__-calc++-scanner.o
g++: error: ./examples/calc++/calc++-scanner.cc: No such file or directory
g++: fatal error: no input files
compilation terminated.
make[3]: ***
[examples/calc++/examples_calc___calc__-calc++-scanner.o] Error 1
make[3]: Leaving directory `/sources/bison-3.0'
make[2]: *** [check-am] Error 2
make[2]: Leaving directory `/sources/bison-3.0'
make[1]: *** [check-recursive] Error 1
make[1]: Leaving directory `/sources/bison-3.0'
make: *** [check] Error 2
But got a solution on this website. Which told me to do the following before issuing make check:
cp Makefile Makefile.bak
sed -i '/calc++/d' Makefile
make check
This solved the issue and all checks were getting a green ok apart from the following three FAILED checks:
430: Variants lalr1.cc parse.assert api.token.constructor FAILED (c++.at:374)
431: Variants lalr1.cc parse.assert api.token.constructor api.token.prefix={TOK_} FAILED (c++.at:375)
432: Variants lalr1.cc parse.assert api.token.constructor api.token.prefix={TOK_} %locations FAILED (c++.at:376)
I tried searching on Google but get nothing.
Any ideas?
It's common mistake. As stated in Chapter 4.6. About the Test Suites:
Experience has shown that there is little to be gained from running
the test suites in Chapter 5. There can be no escaping the fact that
the host system always exerts some influence on the tests in that
chapter, often causing inexplicable failures. Because the tools built
in Chapter 5 are temporary and eventually discarded, we do not
recommend running the test suites in Chapter 5 for the average reader.
The instructions for running those test suites are provided for the
benefit of testers and developers, but they are strictly optional.
Solution is simple - don't run tests for packages compiled in Chapter 5. They will fail and it doesn't mean anything. Tests are important in Chapter 6 when you build your real system.

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

opencv_perf_stitching_Release.gch not generated by cmakefiles

I am trying to configure openCV with codeblocks but It got stuck during mingw32-make step, giving me this error:
[ 94%] Generating
perf_precomp.hpp.gch/opencv_perf_stitching_Release.gch
C:/openCV/opencv/build/x86/mingw/modules/stitching/perf_precomp.hpp:1:0:
fatal error: can't creat e precompiled header
C:/opeCV/opencv/build/x86/mingw/modules/stitching/perf_precomp.hpp.gch/opencv_perf_stitching_Release.gch:
No such file or directory #ifdef __GNUC__ ^ compilation terminated.
modules\stitching\CMakeFiles\pch_Generate_opencv_perf_stitching.dir\build.make:61:
recipe for tar get
'modules/stitching/perf_precomp.hpp.gch/opencv_perf_stitching_Release.gch'
failed mingw32-make[2]: ***
[modules/stitching/perf_precomp.hpp.gch/opencv_perf_stitching_Release.gch]
E rror 1 CMakeFiles\Makefile2:6569: recipe for target
'modules/stitching/CMakeFiles/pch_Generate_opencv_pe
rf_stitching.dir/all' failed mingw32-make[1]: ***
[modules/stitching/CMakeFiles/pch_Generate_opencv_perf_stitching.dir/all]
Er ror 2 Makefile:159: recipe for target 'all' failed mingw32-make:
*** [all] Error 2
I am unable to resolve it!
I am using windows 7 32bit
I met the similar problem that may be caused by cmd input limitation.
The cmd input limitation in win7 is about 8000 characters and in most case that is enough.
However in opencv build,one built component (opencv_perf_stitching_Release) might break this limition due to a long executed command.Because of different folder length for different users,the cutting point in executed command is located at unfixed position.Their error messages are also totally distinctive.In my example,I got a message unrecognized command line option '-sse' but i doubt we met the same problem.
The simplest solutiuon is to reduce your building folder level.In your case,you can change your install path from C:/opeCV/opencv/ to C:/opencv/ and try again.