I am new to omnetpp. In my source file, I include zmq.h header and I can successfully make Makefile with opp_makemake --make-so -f --deep
Next, running make does not give any errors either
Creating shared library: out/gcc-release//libtictoc_r.so
So I am expecting, that zmq library has already been linked.
However, when I run
opp_run -l tictoc_r
I get
<!> Error: Cannot load library 'libtictoc_r.so': ./libtictoc_r.so: undefined symbol: zmq_strerror
Thus I doubt if zmq library had been linked correctly.
By the way, the header files for zmq are located in the standard directory, i.e.
find /usr/include/ -name "*zmq*"
returns
/usr/include/zmq.h
/usr/include/zmq_utils.h
/usr/include/zmq_addon.hpp
/usr/include/zmq.hpp
How could I solve my problem?
Using the header files does not say anything about where the actual shared object file is present. You must add -lzmq (or whatever the library is called) to your linker flags in the project.
The easiest way is to create a makefrag file in the source folder (where the Makefile is generated) and add
LDFLAGS += -lzmq
to it. The generated Makefile will include the makefrag file and that one can add to the linker flags. (the samples/sockets example does this too)
You can also add the required extra linker flags in the IDE's project properties dialog.
Related
i know there a a few posts already about this but I do not seem to be able to get it right.
I am working on a shared project using geany and gcc. The file structure looks something like this:
`/Documents/.../project/ main directory of project with makefile`
`/Documents/.../project/src here are some sourcefiles and headers`
`/Documents/.../project/src/extended here are some other source and header files`
`/Documents/.../project/src/tools other header and source files`
now lets say I am working on a sourcefile in /tools that includes from extened with
#include"/extended/some_header.h"
because my makefile is configured to search for files from /src. However when I am trying to compile the file I am working on right now (by using geany compile option which just calls gcc) I cannot compile it obviously because it cannot find /extended/some_header.h in the /src folder. I have tried adding
-iquotes/Documents/.../project/src
to the gcc call by geany but it doesn't work either.
The -I flag tells the gcc compiler where it should look for the header files. Passing the -Idir to the compiler is appending the dir path to the head of the search list, effectively making this path higher priority than the previously (or system) defined paths. As for the source path - there is no such an option for gcc itself. Each source file passed to the compiler has to have it's path (absolute or relative). In order to work it around, a Makefile can be provided, defining a list of files to be compiled.
I'm trying to figure out how to add header and object files to the standard library so that I can use my custom files as easy as the standard library.
Currently I have to type the path to the header file in the .c file and then link the object file path when compiling.
I would like to just be able to add:
#include <mystdlib.h>
and not worry about linking the object file like I do when I reference the stdio.h header file.
I have searched around, but I fear I'm not using the proper terminology as I don't seem to find the results I need. Am I the first to want to do this, or it is just impossible, and therefore people don't even try?
gcc uses environment variables C_INCLUDE_PATH and LIBRARY_PATH to look for header and library files. Setting them somewhere (eg., your bash_profile) should achieve what you describe:
export C_INCLUDE_PATH="$HOME/include"
export LIBRARY_PATH="$HOME/lib"
Alternatively, the -I and -L flags add directories to the list of directories to be searched for header files and library files, respectively.
edit: As noted by #ChrisStratton below, the library name or object file needs to be explicitly specified. AFAIK, there is no way to make gcc always link against a library (like with libc).
sources:
https://gcc.gnu.org/onlinedocs/gcc/Environment-Variables.html
https://gcc.gnu.org/onlinedocs/gcc/Directory-Options.html
I was originally following this tutorial: http://www.opengl-tutorial.org/miscellaneous/building-your-own-c-application/
just after about half way down, from where it says "Adding a source file in a project"
I created from this my CMakeLists.txt file as so:
cmake_minimum_required (VERSION 2.6)
project (Cube_Project)
find_package(OpenGL REQUIRED)
add_executable(Cube
main.cpp
)
include_directories(
external/glfw-2.7.6/include/
external/glm-0.9.4.0/
external/glew-1.9.0/include/
.
)
set(ALL_LIBS
${OPENGL_LIBRARY}
GLFW_276
GLEW_190
)
target_link_libraries(Cube
${ALL_LIBS}
)
but when I generate the project, I get this error:
ld: library not found for -lGLFW_276
clang: error: linker command failed with exit code 1 (use -v to see invocation)
Any ideas?
I think maybe I'm not using the right names in the set(....) section? My three libs are in a folder called external, which is the top level of the project (i.e. CMakeLists is also here).
I put a zip of the project if anyone wants to take a look at the folder layout of output XCode project structure: http://heather.sh/OpenGL_Project.zip
Thanks,
The library is not in the linker's library search path.
The target_link_libraries command is is very straightforward: It simply passes on all of its arguments to the linker without bothering whether any of those libraries actually exist.
In your case, the GLFW_276 library is missing (and possibly the GLEW_190 as well, since the error occurs before that one is being processed). Make sure the library is actually installed on your system and its filename actually matches the name you use here (eg. libGLFW_276.so).
Once you verify that you have the required file, you need to make sure that the linker is able to find it. If the file is not located in one of the standard directories, use either link_directories to add its location to the search path, or find_library to obtain the full path to the library file, which can then be given to target_link_libraries.
I developed small c application in linux. For this application i placed .h file in
linux standard path (/usr/include). Again i am compiling the same program
Output:
FATA ERROR : xyz.h(my own header file) not found
Do i need to update any variable in gcc or way to solve this problem
Thank You
Place the header file in the same directory as your .c file and use -I. when compiling
gcc -I. main.c -o myprog
You shouldn't place your header files in /usr/include that is meant for the system headers.
Note: you don't actually need the -I. because the current directory is searched by default, nevertheless, it doesn't hurt to add it.
Files specified by include directives are meant to be located in one of the search paths of the complier which are specified with the -I option in many cases (at least for gcc, is it the same for other compilers?). The search paths are verified in the order of definition in the command line.
There are 2 kinds of include directives:
double quoted ones (#include "xyz.h")
angle bracket ones (#include <xyz.h>)
IIRC, the default and first search path for the former is the working directory. For the later, it's compiler dependant, but it's usually /usr/include/.
Depending of the include directive you used, you should pick the right location for your file. Or better, put your file in a good location (say the same place as the including file), and add a search path to your gcc command.
You should separate your header .h files, from system and repository built headers so you don't break anything.
I would recommend making a folder in your home directory called include and just adding it to your path, that way you never have to worry about it again and no need for the -I/flag
Hello Stack Overflow Community,
i am working on a c project to interleave multiple c programs into one binary, which can run the interleaved programs as treads or forks for benchmarking purposes.
Therefore i run make in each program folder of the desired programs and prelink all .o files with "ld -r" to one new .o file. After that i add a specific named function to each of these "big" .o files, which does nothing but run the main() of each program and providing the argc and argv. Then i use objcopy to localize every global Symbol except the unknown ones and the one of my specific function which shall run the main(). At last i link these manipulated .o files together with my program which runs the specific named functions as threads, or forks or after another.
Now to my Question/Problem:
I ran into a problem with static libs. I was using ffmpeg for testing, and it builds static libs such as libavcodc and libavutil and so on. Unfortunately, "ld -r" does not link .a files. So i tried to extract these libs with ar -x and then link the extracted .o files in the way mentioned above to the "big" new .o file. But i did not work because libavcodec and libavutil both include the file ff_inverse.o. That is obviously not a problem when i just build ffmpeg, which will link these static libraries. But still, both libraries include it, so there must be a machanism which makes the choice, which ff_inverse.o to use and to link. So my Question: How does this work? Where is the difference?
The way ld does it with normal linking is to prioritize the libraries. Libraries listed first in the command line are linked in first, and only if symbols still are unresolved does it move on to the next library. When linking static libraries, it ignores the name of each .o file, because the name is unnecessary, only the exported symbols are necessary. You may want to emulate that behavior, by extracting libraries in a sorted order.