Class "Veins::ObstacleControl" not found - omnet++

I have followed step by step the tutorial to install Veins, but when I tried running the example scenario (final step) I ended up with the above error.
The whole error was:
Error in module (cModule) RSUExampleScenario (id=1) during network
setup: Class "Veins::ObstacleControl" not found -- perhaps its code
was not linked in, or the class wasn't registered with
Register_Class(), or in the case of modules and channels, with
Define_Module()/Define_Channel().
TRAPPING on the exception above, due to a debug-on-errors=true
configuration option. Is your debugger ready?
Simulation terminated with exit code: -2147483645 Working directory:
C:/Users/user/src/veins-4.3/examples/veins Command line:
../../../omnetpp-4.6/bin/opp_run.exe -r 0 -n .;../../src/veins
--tkenv-image-path=../../images -l ../../src/veins omnetpp.ini
I don't think I have missed a step during the tutorial as I have tried it two times. I did not make any change in anything, I've just strictly followed the tutorial like a robot, so I cannot provide an MCVE with more details than the tutorial.
Here is what I'm using:
- Windows 7 Pro 64 bits
- SUMO 0.25.0 64 bits
All other steps of the tutorial successfully worked until the final step.

I assume this error occurs when running Veins via the OMNeT++ IDE. Or, if you have compiled it with GCC (The error does not happen if you use CLANG)
There are two ways to bypass this error:
Use the .run as executable from your examples directory, which calls veins/run and includes all the required libraries:
Use opp_run as executable and set dynamic libraries to the directory where libveins.so is located (usually src/veins)
PS: to answer #ChristopSommer questions: Veins::ObstacleControl appears in opp_run -l src/veins -h classes
This could be a solution too, but I never tested it: Compiler flags in Eclipse

Related

Error while generating grpc files (--grpc_out: protoc-gen-grpc: Plugin failed with status code 1.)

I’m trying to run the following command to generate grpc files:
protoc --proto_path=$PROTO_PATH --plugin=protoc-gen-grpc=$PLUGIN_GRPC --grpc_out=$OUT/grpc $PROTO_FILES
This results in the following error:
/Users/MYUSERNAME/Downloads/protoc-gen-grpc-java-1.48.1-osx-aarch_64.exe: program not found or is not executable
Please specify a program using absolute path or make sure the program is available in your PATH system variable
--grpc_out: protoc-gen-grpc: Plugin failed with status code 1.
I made sure the file from the error message is located at that path and has also the correct permissions.
-rwxrwxrwx# 1 MYUSERNAME staff 6334176 10 Aug 00:03 protoc-gen-grpc-java-1.48.1-osx-aarch_64.exe
I also tried running the command as sudo.
Generating java or kotlin files with --java_out=$OUT/java --kotlin_out=$OUT/kotlin
works perfectly fine, so the problem is --grpc_out=$OUT/grpc
I also downloaded multiple versions of the protoc-gen-grpc-java-1.48.1-osx-aarch_64.exe file but it always results in the same error. I also tried replacing all path variables (e.g. $PROTO_PATH) with their corresponding values, without any effect. I’m using MacBook with M1Pro chip.
The problem is that M1 Macs aren't supported. They have copied over the osx-x86_64 binary and renamed it for osx-aarch_64 as a workaround to make it easier to run with Rosetta. See here for where that change was made and here for the full conversation about supporting M1 Macs.

SpringToolSuite 4 and proper OSGi clean

I have SpringToolSuite 4 installed in macOS 11 "Big Sur" running in aarch64 of Zulu11 OpenJDK 11.0.11+9-LTS . I get this error below when starting up and have added the "-clean" parameter to the two ways I use to start up.
From an Applescript: open /Applications/SpringToolSuite4.app" & " --args -clean
Or from the command line: ./SpringToolSuite4 -clean
It would seem the clean parameter is successfully sent as '-Dosgi.clean="true"' is on the last line below. However, it doesn't seem to help as this is reappearing at every restart.
Are there other ways to do an OSGi clean?
I can't edit the ini-file because macOS will clampdown on this and render the whole installation invalid. Since the clean command seems to get passed, that is likely unnecessary.
Error message:
java.lang.UnsatisfiedLinkError: ~/Library/Caches/JNA/temp/jna13221667715595625418.tmp: dlopen(~/Library/Caches/JNA/temp/jna13221667715595625418.tmp, 1): no suitable image found. Did find:
~/Library/Caches/JNA/temp/jna13221667715595625418.tmp: no matching architecture in universal wrapper
~/Library/Caches/JNA/temp/jna13221667715595625418.tmp: no matching architecture in universal wrapper
~/Library/Caches/JNA/temp/jna13221667715595625418.tmp: dlopen(~/Library/Caches/JNA/temp/jna13221667715595625418.tmp, 1): no suitable image found. Did find:
~/Library/Caches/JNA/temp/jna13221667715595625418.tmp: no matching architecture in universal wrapper
~/Library/Caches/JNA/temp/jna13221667715595625418.tmp: no matching architecture in universal wrapper
java.base/java.lang.ClassLoader$NativeLibrary.load0(Native Method)
java.base/java.lang.ClassLoader$NativeLibrary.load(ClassLoader.java:2442)
java.base/java.lang.ClassLoader$NativeLibrary.loadLibrary(ClassLoader.java:2498)
java.base/java.lang.ClassLoader.loadLibrary0(ClassLoader.java:2694)
java.base/java.lang.ClassLoader.loadLibrary(ClassLoader.java:2627)
java.base/java.lang.Runtime.load0(Runtime.java:768)
java.base/java.lang.System.load(System.java:1837)
com.sun.jna.Native.loadNativeDispatchLibraryFromClasspath(Native.java:1018)
com.sun.jna.Native.loadNativeDispatchLibrary(Native.java:988)
com.sun.jna.Native.(Native.java:195)
com.github.dockerjava.zerodep.UnixDomainSocket.(UnixDomainSocket.java:80)
com.github.dockerjava.zerodep.ApacheDockerHttpClientImpl$2.createSocket(ApacheDockerHttpClientImpl.java:124)
com.github.dockerjava.zerodep.shaded.org.apache.hc.client5.http.impl.io.DefaultHttpClientConnectionOperator.connect(DefaultHttpClientConnectionOperator.java:125)
com.github.dockerjava.zerodep.shaded.org.apache.hc.client5.http.impl.io.PoolingHttpClientConnectionManager.connect(PoolingHttpClientConnectionManager.java:409)
com.github.dockerjava.zerodep.shaded.org.apache.hc.client5.http.impl.classic.InternalExecRuntime.connectEndpoint(InternalExecRuntime.java:164)
com.github.dockerjava.zerodep.shaded.org.apache.hc.client5.http.impl.classic.InternalExecRuntime.connectEndpoint(InternalExecRuntime.java:174)
com.github.dockerjava.zerodep.shaded.org.apache.hc.client5.http.impl.classic.ConnectExec.execute(ConnectExec.java:135)
com.github.dockerjava.zerodep.shaded.org.apache.hc.client5.http.impl.classic.ExecChainElement.execute(ExecChainElement.java:51)
com.github.dockerjava.zerodep.shaded.org.apache.hc.client5.http.impl.classic.ExecChainElement$1.proceed(ExecChainElement.java:57)
com.github.dockerjava.zerodep.shaded.org.apache.hc.client5.http.impl.classic.ProtocolExec.execute(ProtocolExec.java:165)
com.github.dockerjava.zerodep.shaded.org.apache.hc.client5.http.impl.classic.ExecChainElement.execute(ExecChainElement.java:51)
com.github.dockerjava.zerodep.shaded.org.apache.hc.client5.http.impl.classic.ExecChainElement$1.proceed(ExecChainElement.java:57)
com.github.dockerjava.zerodep.shaded.org.apache.hc.client5.http.impl.classic.HttpRequestRetryExec.execute(HttpRequestRetryExec.java:93)
com.github.dockerjava.zerodep.shaded.org.apache.hc.client5.http.impl.classic.ExecChainElement.execute(ExecChainElement.java:51)
com.github.dockerjava.zerodep.shaded.org.apache.hc.client5.http.impl.classic.ExecChainElement$1.proceed(ExecChainElement.java:57)
com.github.dockerjava.zerodep.shaded.org.apache.hc.client5.http.impl.classic.RedirectExec.execute(RedirectExec.java:116)
com.github.dockerjava.zerodep.shaded.org.apache.hc.client5.http.impl.classic.ExecChainElement.execute(ExecChainElement.java:51)
com.github.dockerjava.zerodep.shaded.org.apache.hc.client5.http.impl.classic.ExecChainElement$1.proceed(ExecChainElement.java:57)
com.github.dockerjava.zerodep.shaded.org.apache.hc.client5.http.impl.classic.ContentCompressionExec.execute(ContentCompressionExec.java:128)
com.github.dockerjava.zerodep.shaded.org.apache.hc.client5.http.impl.classic.ExecChainElement.execute(ExecChainElement.java:51)
com.github.dockerjava.zerodep.shaded.org.apache.hc.client5.http.impl.classic.InternalHttpClient.doExecute(InternalHttpClient.java:178)
com.github.dockerjava.zerodep.shaded.org.apache.hc.client5.http.impl.classic.CloseableHttpClient.execute(CloseableHttpClient.java:67)
com.github.dockerjava.zerodep.ApacheDockerHttpClientImpl.execute(ApacheDockerHttpClientImpl.java:157)
com.github.dockerjava.zerodep.ZerodepDockerHttpClient.execute(ZerodepDockerHttpClient.java:8)
com.github.dockerjava.core.DefaultInvocationBuilder.execute(DefaultInvocationBuilder.java:228)
com.github.dockerjava.core.DefaultInvocationBuilder.get(DefaultInvocationBuilder.java:202)
com.github.dockerjava.core.DefaultInvocationBuilder.get(DefaultInvocationBuilder.java:75)
com.github.dockerjava.core.exec.InfoCmdExec.exec(InfoCmdExec.java:24)
com.github.dockerjava.core.exec.InfoCmdExec.exec(InfoCmdExec.java:14)
com.github.dockerjava.core.command.AbstrDockerCmd.exec(AbstrDockerCmd.java:35)
org.springframework.ide.eclipse.boot.dash.docker.runtarget.DockerRunTarget.connect(DockerRunTarget.java:130)
org.springframework.ide.eclipse.boot.dash.cloudfoundry.RemoteBootDashModel.lambda$2(RemoteBootDashModel.java:77)
org.springframework.ide.eclipse.boot.dash.model.remote.RefreshStateTracker.call(RefreshStateTracker.java:80)
org.springframework.ide.eclipse.boot.dash.model.remote.RefreshStateTracker.lambda$3(RefreshStateTracker.java:123)
org.springsource.ide.eclipse.commons.frameworks.core.util.JobUtil$6.run(JobUtil.java:193)
org.eclipse.core.internal.jobs.Worker.run(Worker.java:63)
-Dosgi.clean="true"
The issue mentioned above is this: https://github.com/spring-projects/sts4/issues/684
It is not related to OSGi, so -clean doesn't help here. The fix will be part of STS 4.12.1 release, but you could grab a nightly CI build to get the fix right away from here: http://dist.springsource.com/snapshot/STS4/nightly-distributions.html
On a related note: Once you started STS at least one you should be able to modify the .ini file without issues. If macOS still complains about it, you can remove the quarantine flag from the app:
sudo xattr -r -d com.apple.quarantine SpringToolSuite4.app
This will avoid the error message and let you start your STS4 install even after editing the content.

GnuCOBOL entry point not found

I've installed GnuCOBOL 2.2 on my Ubuntu 17.04 system. I've written a basic hello world program to test the compiler.
1 IDENTIFICATION DIVISION.
2 PROGRAM-ID. HELLO-WORLD.
3 *---------------------------
4 DATA DIVISION.
5 *---------------------------
6 PROCEDURE DIVISION.
7 DISPLAY 'Hello, world!'.
8 STOP RUN.
This program is entitled HelloWorld.cbl. When I compile the program with the command
cobc HelloWorld.cbl
HelloWorld.so is produced. When I attempt to run the compiled program using
cobcrun HelloWorld
I receive the following error:
libcob: entry point 'HelloWorld' not found
Can anyone explain to me what an entry point is in GnuCOBOL, and perhaps suggest a way to fix the problem and successfully execute this COBOL program?
According to the official manual of GNUCOBOL, you should compile your code with:
cobc -x HelloWorld.cbl
then run it with
./HelloWorld
You can also read GNUCOBOL wiki page which contains some exmaples for further information.
P.S. As Simon Sobisch said, If you change your file name to HELLO-WORLD.cbl to match the program ID, the same commands that you have used will be ok:
cobc HELLO-WORLD.cbl
cobcrun HELLO-WORLD
Can anyone explain to me what an entry point is in GnuCOBOL, and perhaps suggest a way to fix the problem and successfully execute this COBOL program?
An entry point is a point where you may enter a shared object (this is actually more C then COBOL).
GnuCOBOL generates entry points for each PROGRAM-ID, FUNCTION-ID and ENTRY. Therefore your entry point is HELLO-WORLD (which likely gets a conversion as - is no valid identifier in ANSI C - you won't have to think about this when CALLing a program as the conversion will be done internal).
Using cobcrun internally does:
search for a shared object (in your case HelloWord), as this is found (because you've generated it) it will be loaded
search for an entry point in all loaded modules - which isn't found
There are three possible options to get this working:
As mentioned in Ho1's answer: use cobc -x, the reason that this works is because you don't generate a shared object at all but a C main which is called directly (= the entry point doesn't apply at all)
preload the shared object and calling the program by its PROGRAM-ID (entry point), either manually with COB_PRE_LOAD=HelloWorld cobcrun HELLO-WORLD or through cobcrun (option available since GnuCOBOL 2.x) cobcrun -M HelloWorld HELLO-WORLD
change the PROGRAM-ID to match the source name (either rename or change the source, I'd do the second: PROGRAM-ID. HelloWorld.)

On running my first simulation of castalia, i get the following error

Simulation terminated with exit code: 139 Working directory: /home/roopali/omnetpp-4.6/samples/Castalia_proj/Simulations/Parameters Command line: ../../src/Castalia_proj -r 0 -n ..:../../src First_Obj.ini
Environment variables: PATH=/home/roopali/omnetpp-4.6/bin::/home/roopali/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games LD_LIBRARY_PATH=/home/roopali/omnetpp-4.6/lib:: OMNETPP_IMAGE_PATH=/home/roopali/omnetpp-4.6/images
I have tried making this simulation using the steps on page https://chevy67.wordpress.com/tag/castalia/
The blog post you linked (and tried to follow instructions from) refers to a very old version of Castalia. Follow the installation guidelines found in the official repo for Castalia:
https://github.com/boulis/Castalia
After you have installed Castalia successfully, read the manual (found again in the above link), especially Chapter 3, to run your first simulation.

Network setup and class "Veins::ObstacleControl" not found

I will be grateful if you help me to figure out my problems with veins:
I successfully installed veins 4a2 and sumo 0.21.0 and Omnet 4.4 , the simulation example works fine.
Next, I imported Crypto++ 5.6.3 in the workspace as a new project under C/C++ → Existing Code as Makefile Project. Then I linked it to veins as follow:
in Project References I selected the Crypto++
in Makemake options, I select Link → and write Crypto++
I include in my code #include< rsa.h> etc… , it is recognized and there is no syntax errors, but when I run the simulation (omnet.ini), opp_run.exe crash.
The system is Windows 10 and the error is :
<!> Error in module (cCompoundModule) RSUExampleScenario (id=1) during network setup: Class "Veins::ObstacleControl" not found -- perhaps its code was not linked in, or the class wasn't registered with Register_Class(), or in the case of modules and channels, with Define_Module()/Define_Channel().
TRAPPING on the exception above, due to a debug-on-errors=true configuration option. Is your debugger ready?
Simulation terminated with exit code: -2147483645
Working directory: C:/Simulateur/veins-4a2/veins-veins-4a2/examples/veins
Command line: c:/Simulateur/omnetpp-4.4-src-windows/omnetpp-4.4/bin/opp_run.exe -r 0 -n .;../../src/veins --tkenv-image-path=../../images omnetpp.ini
Environment variables:
OMNETPP_ROOT=c:/Simulateur/omnetpp-4.4-src-windows/omnetpp-4.4
PATH=;c:\Simulateur\omnetpp-4.4-src-windows\omnetpp-4.4\bin;c:\Simulateur\omnetpp-4.4-src-windows\omnetpp-4.4\msys\bin;c:\Simulateur\omnetpp-4.4-src-windows\omnetpp-4.4\mingw\bin;c:/Simulateur/omnetpp-4.4-src-windows/omnetpp-4.4/ide/jre/bin/client;c:/Simulateur/omnetpp-4.4-src-windows/omnetpp-4.4/ide/jre/bin;c:/Simulateur/omnetpp-4.4-src-windows/omnetpp-4.4/ide/jre/lib/i386;.;C:\Simulateur\omnetpp-4.4-src-windows\omnetpp-4.4\msys\local\bin;c:\Simulateur\omnetpp-4.4-src-windows\omnetpp-4.4\mingw\bin;C:\Simulateur\omnetpp-4.4-src-windows\omnetpp-4.4\msys\bin;c:\Simulateur\omnetpp-4.4-src-windows\omnetpp-4.4\bin;c:\Windows\system32;c:\Windows;c:\Windows\System32\Wbem;c:\Windows\System32\WindowsPowerShell\v1.0\;c:\Program Files (x86)\ATI Technologies\ATI.ACE\Core-Static;c:\Program Files (x86)\AMD\ATI.ACE\Core-Static;c:\Windows\system32\config\systemprofile\.dnx\bin;c:\Program Files\Microsoft DNX\Dnvm\;c:\Program Files\Microsoft SQL Server\120\Tools\Binn\;c:\Program Files (x86)\Skype\Phone\;c:\Simulateur\omnetpp-4.4-src-windows\omnetpp-4.4;
OMNETPP_IMAGE_PATH=c:\Simulateur\omnetpp-4.4-src-windows\omnetpp-4.4\images
Question: How to link another C++ library, like Crypto++, to my veins project?
Veins generates a dynamic library of its simulation modules. When using opp_run you will need to tell it to load this library. Otherwise the simulation will not be able to instantiate any of Veins’ modules.
Try doing the Veins tutorial to see what command line parameters OMNeT++ uses to launch the simulation.

Resources