I want to derive a class from UdpBasicApp of inet in Oment++. Indeed, I want to write my own application. I wrote the following code, but when I compile the project, I have an error. For compiling this project without any error, what should I do?
Creating executable: out/clang-release//Manet_1.1.exe
out/clang-release//MyApp.o:(.rdata[_ZTIN4inet11UdpBasicAppE]+0x10): undefined reference to `typeinfo for inet::ApplicationBase'
out/clang-release//MyApp.o:(.rdata[_ZTV5MyApp]+0x640): undefined reference to `non-virtual thunk to inet::OperationalBase::handleOperationStage(inet::LifecycleOperation*, int, inet::IDoneCallback*)'
clang++.exe: error: linker command failed with exit code 1 (use -v to see invocation)
make: *** [Makefile:101: out/clang-release//Manet_1.1.exe] Error 1
MyApp.h
#include "../../inet/src/inet/applications/udpapp/UdpBasicApp.h"
using namespace inet;
class MyApp : public UdpBasicApp
{
public:
};
MyApp.c
#include "MyApp.h"
Define_Module(MyApp);
MyApp.net
import inet.applications.udpapp.UdpBasicApp;
simple MyApp extends UdpBasicApp
{
#class(MyApp);
}
Clearly you are working in your own project which does NOT properly link with the INET model. You MUST select INET as a project reference in your own project's project properties dialog. That will add INET's include folder to the include path, so you would need to (properly) write only
#include "inet/applications/udpapp/UdpBasicApp.h"
instead of
#include "../../inet/src/inet/applications/udpapp/UdpBasicApp.h"
And the linker command line would be also modified to link with the INET shared library properly.
Related
As default, Forth has only a little amount of working libraries so that everything has to be programmed from scratch. The reason is, that the stackbased Forth virtual machine identifies itself as a slim system.
According to the Gforth manual, it's possible to use existing C libraries and get access to precompiled graphics libraries and game-engines written in C. Before it's possible to include the C library in Forth, it's a good idea to test the library within a normal C project.
I've created a library in C from scratch. It provides an add function and can be called from the main program. The files are compiled and linked and it works fine.
### add.c ###
int add(int a, int b) {
return a + b;
}
### add.h ###
int add(int, int);
### main.c ###
#include <stdio.h>
#include "add.h"
void main() {
printf("5 + 7 = %d\n", add(5,7));
}
### compile ###
gcc -c -fPIC add.c
gcc -c main.c
gcc main.o add.o
./a.out
5 + 7 = 12
The plan is to use this precompiled c-library from Forth. The Gforth compiler provides a special keyword for that purpose which connects a Forth program with a C library. Unfortunately, I get an error message saying that the library wasn't found. Even after copying it manually to the Gforth folder, the error message doesn't disappear.
### Forth source code ###
\c #include "add.h"
c-function add add n n -- n
5 7 add .
bye
### Execution ###
gforth "main.fs"
/home/user1/.gforth/libcc-tmp/gforth_c_7F5655710258.c:2:10: fatal error: add.h: No such file or directory
#include "add.h"
^~~~~~~
compilation terminated.
in file included from *OS command line*:-1
b.fs:3: libtool compile failed
5 7 >>>add<<< .
Backtrace:
$7F56556BD988 throw
$7F56556F9798 c(abort")
$7F56556F9F08 compile-wrapper-function
gforth: symbol lookup error: /home/user1/.gforth/libcc-tmp/.libs/gforth_c_7F0593846258.so.0: undefined symbol: add
### Copy missing file and execute again ###
cp add.h /home/user1/.gforth/libcc-tmp/
gforth "main.fs"
gforth: symbol lookup error: /home/user1/.gforth/libcc-tmp/.libs/gforth_c_7F5256AC2258.so.0: undefined symbol: add
What's wrong with the “Forth-to-C interface”?
You have to declare add as a function for export, compile it as a shared library (e.g. libadd.so) and add this library using the add-lib word, see Declaring OS-level libraries.
s" add" add-lib
NB: prefix 'lib' and suffix '.so' are added automatically.
I am trying to use LEDA-6.3 library in Omnet++ 4.2.2. I installed LEDA and ran a simple program using it without problem from Ubuntu terminal. However, when I port the code to Omnet++, it fails. Below is my simple code.
#include <LEDA/graph/graph.h>
#include <omnetpp.h>
class cLeda : public cSimpleModule
{
protected:
virtual void initialize();
};
Define_Module(cLeda);
void cLeda::initialize()
{
EV << "TestLEDA";
graph g;
g.read("nsfnet.txt");
EV << "No. nodes = " <<g.number_of_nodes() << endl;
}
I configured for LEDA paths for compiler and linker as follows: Project -> Properties --> Choose C/C++ General -> Path and Symbols and added:
For Library Paths: /home/grsst/LEDA-6.3/incl
For Libraries: /home/grsst/LEDA-6.3/libleda.a (I didn't add libleda.o
since it doesn't work even with Ubuntu command line)
For Library Paths: /home/grsst/LEDA-6.3
When I compile, the I got errors as follows:
Description Resource Path Location Type
make: *** [all] Error 2 TestLeda C/C++ Problem
make[1]: *** [../out/gcc-debug/src/TestLeda] Error 1 TestLeda C/C++ Problem
undefined reference to `leda::graph::~graph()' cLeda.cc /TestLeda/src line 26 C/C++ Problem
undefined reference to `leda::graph::graph()' cLeda.cc /TestLeda/src line 24 C/C++ Problem
undefined reference to `leda::graph::read(leda::string)' cLeda.cc /TestLeda/src line 25 C/C++ Problem
undefined reference to `leda::memory_manager_init::~memory_manager_init()' TestLeda line 145, external location: /home/grsst/LEDA-6.3/incl/LEDA/system/memory_std.h C/C++ Problem
undefined reference to `leda::memory_manager_init::memory_manager_init()' TestLeda line 145, external location: /home/grsst/LEDA-6.3/incl/LEDA/system/memory_std.h C/C++ Problem
undefined reference to `leda::memory_manager::deallocate_bytes(void*, unsigned int)' TestLeda line 52, external location: /home/grsst/LEDA-6.3/incl/LEDA/internal/handle_types.h C/C++ Problem
undefined reference to `leda::std_memory_mgr' TestLeda line 52, external location: /home/grsst/LEDA-6.3/incl/LEDA/internal/handle_types.h C/C++ Problem
undefined reference to `leda::string::string(char const*)' cLeda.cc /TestLeda/src line 25 C/C++ Problem
I appreciate any idea to help me to make it work. Thanks a million.
OMNeT++ project usually uses Makefile. Try to add LEDA libraries as a Makefrag.
Go to Project Properties, choose OMNeT++ | Makemake | select src | Options | Custom | Makefrag and write:
INCLUDE_PATH += -I/home/grsst/LEDA-6.3/incl
LIBS += -L/home/grsst/LEDA-6.3 -lleda
I am trying to get started with the VJoy virtual joystick, but i am having trouble getting it up and running.
I keep getting this error:
main.cpp|14| undefined reference to `_imp__vJoyEnabled'
I am trying to get it running using the code below.
#include <iostream>
#include <windows.h>
#include <stdlib.h>
#include "public.h"
#include "vjoyinterface.h"
using namespace std;
int main()
{
// Get the driver attributes (Vendor ID, Product ID, Version Number)
if (!vJoyEnabled())
{
cout << "Function vJoyEnabled Failed - make sure that vJoy is installed and enabled\n" << endl;
}
cout << "Hello world!" << endl;
return 0;
}
Within Codeblocks i have set the compiler to compile with C++11.
Also within Codeblocks i have linked the library (Project build options -> linker settings -> add library)
I have also tried playing with the Search Directory, but i can't seem to get it working.
Any ideas what i am missing?
I found out i was linking to the wrong locations. Unfortunately there wasn't a clear error indicating this.
So the solution to this problem(in my case):
-Make sure you link to the right library locations
-Move the libraries and all of its associated files inside of the codeblocks project folder
-Add the library to the linked libraries(Project build options -> Linker settings -> Link libraries)
-Add the library locations to the search directories(Project build options -> Search directories -> Linker -> add)
I am trying to design a network(Random Graph) in omnet++ where I want to parse the network nodes using Lemon Graph Library. I have installed the library and it works fine if I try to compile any normal c++ file with nodes and edges in any graph using command line g++ -o file file.cpp/cc -lemon. But when i tried it with one of my omnet++ project(which has nothing in it now) the code is as below
#include <omnetpp.h>
#include <iostream>
#include <lemon/list_graph.h>
using namespace lemon;
using namespace std;
class Facility : public cSimpleModule
{
protected:
virtual void initialize();
virtual void handleMessage(cMessage *msg);
};
Define_Module(Facility);
void Facility :: initialize(){
}
void Facility :: handleMessage(cMessage *msg){
}`
the include headers are in angle brackets(not to be confused with double quotes). So when i build the code I get the following errors:
Description Resource Path Location Type
‘class cEnvir’ has no member named ‘push_back’ PSUC line 686, external location: /usr/local/include/lemon/bits/graph_extender.h C/C++ Problem
‘class cEnvir’ has no member named ‘push_back’ PSUC line 687, external location: /usr/local/include/lemon/bits/graph_extender.h C/C++ Problem
‘test’ does not name a type test.cc /ztest line 9 C/C++ Problem
invalid use of qualified-name ‘cSimulation::getActiveEnvir’ PSUC line 69, external location: /home/vijay/omnetpp-4.6/include/cenvir.h C/C++ Problem
make: *** [out/gcc-debug//psuc.o] Error 1 PSUC C/C++ Problem
make: *** [out/gcc-debug//test.o] Error 1 ztest C/C++ Problem
no matching function for call to ‘lemon::AlterationNotifier<lemon::GraphExtender<lemon::ListGraphBase>, lemon::ListGraphBase::Arc>::add(cEnvir&)’ PSUC line 688, external location: /usr/local/include/lemon/bits/graph_extender.h C/C++ Problem
Why doesn't the Omnet++ code get compatible with Lemon graph Library?
OMNeT++ includes a macro definition for ev in cEnvir.h (which is included from omnetpp.h)
#define ev (*cSimulation::getActiveEnvir())
Because you include omnetpp.h before graph_extender.h, this macro is expanded in the library's header file, which conflicts with its use as a variable name in
ev.push_back(Parent::direct(edge, true));
A simple solution would be to include graph_extender.h before omnetpp.h, so the macro is not yet defined when graph_extender.h is read. If this is not possible, you might have some luck with manually undefining the macro before (and possibly restoring the definition after), as follows.
#pragma push_macro("ev")
#undef ev
#include "graph_extender.h"
#pragma pop_macro("ev")
I want to use TraCIMobility.h from Veins to change some SUMO variables for visualization.
I receive an error, when building my project. TraCIMobility.h can't find BaseMobility.h, which is also part of Veins. Are there some problems inside the Veins project? I built it one more time, but it can't find its own modules. I added Veins to my project with Project->Properties->Project References.
This is the error:
10:12:16 **** Incremental Build of configuration gcc-debug for project CloudBasedCSW ****
make MODE=debug CONFIGNAME=gcc-debug all
cd src && make
make[1]: Entering directory `/c/work/Cloud_Curve_Speed_Warning/trunk/src/CloudBasedCSW/src'
visualization/Visualization.cc
In file included from ./visualization/Visualization.h:19:0,
from visualization/Visualization.cc:16:
C:/Tools/veins/src/veins-3.0/src/modules/mobility/traci /TraCIMobility.h:31:26: fatal error: BaseMobility.h: No such file or directory
make[1]: Leaving directory `/c/work/Cloud_Curve_Speed_Warning/trunk/src/CloudBasedCSW/src'
compilation terminated.
make[1]: *** [../out/gcc-debug/src/visualization/Visualization.o] Error 1
make: *** [all] Error 2
10:12:17 Build Finished (took 726ms)
This is the header, which includes TraCiMobility.h
#ifndef VISUALIZATION_H_
#define VISUALIZATION_H_
#include <omnetpp.h>
#include "modules/mobility/traci/TraCIMobility.h"
class Visualization: public cSimpleModule{
public:
Visualization();
virtual ~Visualization();
void initialize();
void handleMessage(cMessage *msg);
void setIce(std::string laneId);
void removeIce(std::string laneId);
};
#endif /* VISUALIZATION_H_ */
You didn't say which Veins version you are using, so I am assuming the newest, Veins 4a2. Here, you will need to specify the include path like so
#include "veins/modules/mobility/traci/TraCIMobility.h"
To clarify: the --meta:auto-include-path option to opp_makemake will always generate a -I include path that includes all of the missing components to make the include work (that is, writing as little as #include "traci/TraCIMobility.h" would yield a compiler flag of -I..../veins/src/veins/modules/mobility), but without adding a -I include path to the root of Veins, none of the includes within work. By specifying the full path to the file (relative to the source root of Veins), you are forcing opp_makemake to generate a -I include path of -I..../veins/src, which is what is needed to build Veins.