When installing openssl using brew, a part of the response is outputted:
For compilers to find openssl you may need to set:
export LDFLAGS="-L/usr/local/opt/openssl/lib"
export CPPFLAGS="-I/usr/local/opt/openssl/include"
and the following could be used to compile a C++ file.
g++ file.cpp -I/usr/local/opt/openssl/include
What is the -I and the -L for?
-L means the path is a dir which contains Libraries for linking (adds the path to the set of dirs the linker will search)
-I means there are header files to Include in the given dir.
Related
I'm trying to generate a mex function usigin external libraries. I'm using Ubuntu 18 and Matlab R2021a.
In particular I want to compile my file.cpp that uses my cpp library called model.
What I did is
mex -I<path_library_include> -L<path_library_so_file> -lmodel.so -lboost_system -lstdc++ file.cpp -v
where in -I i put the path where is the include of the library in -L the path in which the libmodel.so is located, then I added 2 more libraries and at the end the source file that I want to compile.
In this way I can compile my source but when I try to execute the mex function I get:
libmodel.so: cannot open shared object file: No such file or directory
I also tested the library outside matlab and works fine, this is the command that I use to compile the library outside Matlab
gcc -Wall -I<path_library_include> -L<path_library_so_file> main.cpp -lmodel -lboost_system -lstdc++ -o main
What could be the problem with Matlab?
Thanks to 273K that gave me the right direction.
The problem was that the LD_LIBRARY_PATH was not configured well in fact running /sbin/ldconfig -v my library was not present. So to add the shared library i created a new file as root in /etc/ld.so.conf.d/ called mylib.conf it is not important the name just the extension. Then I run
sudo ldconfig
after that the library was present in fact running
/sbin/ldconfig -v | grep model
where model is the name of my library. it is possible to see the output.
I'm compiling a c++ program using g++ and i am using two libraries called libsdl2-dev and libsdl2-image-dev
I installed both these libraries in my ubuntu machine with the commands
apt install libsdl2-dev libsdl2-image-dev and when I compile the program everything works fine. Then I copied these libraries from /usr/lib/x86_64-linux-gnu/ to my working dir with the binary file to be able to give this folder to someone else.
The problem comes when the user that hasn't installed these libraries tries to open my program by writing ./main (the binary file). Since he hasn't installed these libraries he would get an error like "can't open shared object: no such file or directory".
This happens because the binary file looks for these libraries in /usr/lib etc...
What i need
I need that my binary file looks for these libraries in the same folder,and not in /usr/lib/x86 etc.., from what I read I have to do something like rpath
The IDE used is Sublime Text and the syntax used to compile all my files is this:
g++ -c src/*.cpp -std=c++14 -m64 -g -Wall -I include && g++ *.o -o bin/debug/main -lSDL2main -lSDL2 -lSDL2_image && ./bin/debug/main`
Structure of folders
I got the project dir with and inside that i got 4 more directories, each one called: bin (with the debug subdirectory, where we got the final compile), include (with hpp files), res (with all textures), and src with all cpp files to compile, the other files are project files and .o files
I'm using Ubuntu 20.04-2 LTS and the same is for the other user's PC
Thanks in advance for any help!
That's because the dynamic linker loading runtime dependencies looks for them in some specified locations, which are "by default" your system library directories (where those libraries got installed by apt).
The other user should ideally install those libraries too (which could be done "automatically" if you build a .deb package with proper dependencies)
Otherwise you would have to change the runpath of your program by adding -Wl,-rpath='$ORIGIN', which makes the dynamic linker look for dependencies just where the binary is located.
$ORIGIN here is a special variable meaning "this executable" which is what you wanted to achieve.
see rpath
and A description of RPATH $ORIGIN
I found a way to resolve!
I used the program patchelf to add an rpath to my directory (linked to the binary file) now everything works
use ldd ./bin/debug/main to check the library
export LD_LIBRARY_PATH =$LD_LIBRARY_PATH:"your library path"
run the program,if this is not work. use patchelf to change the rpath to you r library
I'm trying to link a game library for my game project in C++. I am using the g++ compiler and Atom Code Editor. Also on a Windows machine.
To link the library it needs to link those things:
Include path
Library path
Additional dependencies
The main.cpp file is at ProjectRoot/src/main.cpp and the library is at ProjectRoot/deps/lib_name
Inside the library there is and include folder, with the .h file for including, and a lib folder, with the .lib file. It's a static linking library.
So far, I've tried the following commands:
g++ -o ExecutableName.exe -I /deps/lib_name/include -L /deps/lib_name/lib src/main.cpp
Well, that didn't work though... It said that there was no such file or directory as library_name.h...
I need to know if I'm doing anything wrong and also how to specify the additional dependencies.
Every thing is correct . You just forgot to link the libraries . Do it as follows -
g++ -o ExecutableName.exe -I /deps/lib_name/include -L /deps/lib_name/lib src/main -l[library name] -l[library name]
I'm getting the error
c:\mingw\lib\gcc\mingw32\6.3.0\include\c++\cstdlib:75:25: fatal error: stdlib.h: No such file or directory
#include_next <stdlib.h>
when adding C:\MinGW\include to the compiler include search path:
echo "#include <cstdlib>" | g++ -x c++ - -isystem C:/MinGW/include -o /dev/nul
But CMake does this because some libraries (libcurl e.g.) are installed into C:\MinGW hence the curl include dir is C:\MinGW\include
Am I doing something wrong or is this a bug in MinGW?
I'm using MinGW 5.0.1.
What works: echo "#include <cstdlib>" | g++ -x c++ - -IC:/MinGW/include -o /dev/nul but I don't want to include the curl include dirs etc. as non-system includes.
Related to mingw/include/c++/cstdlib: stdlib.h: No such file or directory
Background: I'm using cmake to generate the makefiles. So there is a find_package(Curl) and a include_directories(SYSTEM CURL_INCLUDE_DIRS) in the CMakelists.txt. As libcurl is installed to C:/MinGW the CURL_INCLUDE_DIRS will be C:/MinGW/include and hence the -isystem include. I don't want to omit the SYSTEM because this might cause warnings to be generated for the libcurl headers. Of course there are more libraries that are also installed in the same way and I want to keep the cmake files portable.
The problem lies in the use of include_next of the C++ standard header. According to https://gcc.gnu.org/onlinedocs/cpp/Wrapper-Headers.html it will include the header searching the list of header file directories after the directory in which the current file was found. The standard include directories (using g++ -v) are (corrected):
c:\mingw\lib/gcc/mingw32/6.3.0/include/c++
c:\mingw\lib/gcc/mingw32/6.3.0/include/c++/mingw32
c:\mingw\lib/gcc/mingw32/6.3.0/include/c++/backward
c:\mingw\lib/gcc/mingw32/6.3.0/include
c:\mingw\include
c:\mingw\lib/gcc/mingw32/6.3.0/include-fixed
c:\mingw\mingw32/include
Hence the cstdlib will be found in c:\mingw\lib/gcc/mingw32/6.3.0/include/c++ and include_next "stdlib.h" will go further down this list and will find it in c:\mingw\include.
Now the problem: Installing the libraries into C:\mingw (using the lib, bin and include folders from the library) will make CMake correctly find them there and add the C:\mingw\include folder explicitly to the include list. The 2 cases work out as following:
Adding as -I: This will be ignored by g++ with ignoring ... as it is a non-system directory that duplicates a system directory
Adding as -isystem: This will prepend the directory to the list above and remove it from the rest as a duplicate (verified with the -v option). This means that when cstdlib is found and include_next is evaluated it will search only downward the list. But the directory containing the stdlib.h is not down the list anymore but upwards and therefore not searched. Hence the error.
Note: I found another definition of include_next which only discards the directory containing the header. That would work in this case but can lead to loops and was changed to the described behaviour.
Solution so far is simply installing or copying the libraries to C:\mingw\mingw32 instead.
I've installed at my win8.1 mingw and I would like to compile my program.
When I use command:
g++ -o test test.cpp -lboost_unit_test_framework-mt
I got an error:
no such file od directory:
"#include boost/test/unit_test.hpp" // in "<>" ofc.
when I use my msVS it works fine.
You also must use the -L and the -I option to specify the directories where the boost libraries and headers are located:
g++ -I<path_to_headers> -o test test.cpp -L<path_to_library> -lboost_unit_test_framework-mt
Note for the headers path that should be the path containing the boost directory.