I have two projects in eclipse CDT on my Mac. One is a shared library the other is a C++ project that uses the shared library. I am trying to use the shared library, and have gotten it to compile but it will not run. When i try to run it i get a image not found error.
I haven't been able to figure out how to add my library to the path directory or ld_library_path or what every other path I need to add it to so that it can be linked to at run time. I already added it as a reference in my other project which has correctly setup run time linking for me but i need help setting up run time linking.
When I try to run a program which uses another shared-link library, also I want to run the program inside the eclipse. Here is what I did:
Insert a variable environment LD_LIBRARY_PATH="where you shared lib file is" in "Run/Debug Settings" and problem solved.
I had the some problem, the solution:
Insert a variable environment DYLD_LIBRARY_PATH = ${workspace_loc:/sharedlib/Debug} into run configuration.
Related
I am using Eclipse Eclipse 2022-09 with CDT 10.7.1202208222120 on Fedora 37.
I am working on a simple C++ testapplication (libTest.cpp) which should use code from 2 shared librarys (libBasexCpp and libBasexSocket).
All 3 sources compile without errors and building libTest also completes without error. In the Properties -> Settings -> Build Artifact dialog for libBasexCpp and libBasexSocket, I have chosen not to use a Output Prefix (prefix is ""). In the debug directorys, libBasexCpp.so and libBasexSocket.so are created.
When I try to run the testapplication as a local C/C++ application, I first have to choose which local application should be run , liblibTest or libTest.
Executing either one of the 2 results in a message, saying that liblibBasexCpp can not be found.
I have added Library Paths (DYLD_LIBRARY_PATH = ${workspace_loc:/libBasexCpp/Debug};${workspace_loc:/libBasexSocket/Debug} as Environmentvariable to the run configuration.
How can I configure Eclipse in such way that it loads the shared library's?
Basically, to configure the shared librarys and the test application, I followed the instructions as I found on Shared libraries with Eclipse CDT and cygwin on Windows.
What was missing therein was the instruction to add in the Run configuration the variable LD_LIBRARY_PATH containing the paths to both libraries.
After adding this variable, the test application worked.
I currently have my Other Linker Options as:
Unfortunately, this means that I can only ever run the executable when libsfml-dev is installed, which is undesirable for game development. Whenever I even change the Other Linker Options or Search Directories>Linker will cause an error along the lines of:
error while loading shared libraries: libsfml-graphics.so.2.2.0: cannot open shared object file: No such file or directory. I assume this error happens because the libraries are relative, so it is completely portable.
EDIT:
I am using Code::Blocks (as you can see from the image), and I would like to know how I can link to the libraries relatively. They link fine when it is run from Code::Blocks, but when I run the executable I get the above error. My current Code::Blocks options are:
Linker Options:
(Other linker options is empty)
Search Directories:
Your first linker options would be the correct ones.
The Library libsfml-dev is only required on the compile machine.
There must also be another package which actually supplies the .so files. That one will also be required on the machine running the executable unless you package those .so files with your executable. In that case you probably need a script that sets LD_LIBRARY_PATH to the local directory containing the packaged .so files and then executes your program.
In a project I am working on I depend on a couple of external libraries that are necessary for the program to run. On my local machine they can be found in usr/local/lib and everything works like a charm.
Now, when I build my Release I want these libraries to be added to the build
(I want to end up with my executable and all necessary libs) and configure it, such that when I run the program from commandline, it knows the libraries are in lib.
I could manually add all the libraries in this folder on my local machine and configure my project so that it can find the libraries here, but, even using variables, it still inserts a local path, so using it on other machines does not work. Or is there a way to do this starting from the project path?
Is this possible using CDT?
If you use relative paths to the project folder, that should be totally portable, as long as the other machines can run such libraries. For example if your project is in /home/Fristi/project, you could just copy all your static libraries into ./libs (which actually points to /home/Fristi/project/libs and add ./libs in your makefile or CDT configuration.
I have a C++ project I am importing and it is using activemq libraries. After I import the project, I set the LD_LIBRARY_PATH variable under environment to point to
/usr/local/include/activemq-cpp-3.4.2
This allows the project to see all the libraries for activemq and I can see it show up in my includdes folder in the project explorer. When I go to Build Project, I am getting tons of errors to references of includes/objects that are inside /usr/local/include/activemq-cpp-3.4.2. The interesting thing is that the binary is still being produced, yet there are about 80 errors due to the library files not being found. How is the binary being made? Also, what must I do to the LD_LIBRARY_PATH environment variable so the project is properly including those files?
I have tried launching eclipse with the
./eclipse -clean
But that didn't seem to help. Any ideas are welcome, and thank you in advance!
EDIT:
I am using Eclipse Juno with C++ verseion 4.1.2 on Redhat 4.X
LD_LIBRARY_PATH isn't used for locating include directories. It's used to inform the system of a list of directories to search for shared libraries: compiled support libraries, not e.g. SDKs for Eclipse.
You should use the project's properties to add to the places that are searched for includes: C++ General->Paths and Symbols->Includes
Also use the properties - not LD_LIBRARY_PATH - if you do need to link against other libraries: : C++ General->Paths and Symbols->Library Paths
Finding header files is not the purpose of LD_LIBRARY_PATH. That environment variable is to tell the OS where to start looking for shared libraries — *.so files. The OS looks for those when preparing the execute your program. The compiler uses the include path to search for headers when it encounters an #include statement in your source code.
Don't modify LD_LIBRARY_PATH to affect compilation of your program.
Eclipse lets you set your include path in your project options.
I have a very simple question that I've been trying to figure out for the last 6 hours or so. I want to simply build a dynamic library on Mac OS X, and then build an application using that library. I've created the .dylib and compiled the test application with it, but when I run the application I get:
Joes-Mac-Pro:Desktop Joe$ ./test
dyld: Library not loaded: ./lib/simple_library.dylib
Referenced from: /Users/Joe/Desktop/./test
Reason: image not found
Trace/BPT trap: 5
I've tried making a lib folder in the executable directory and putting the dylib inside, same error. I've tried putting the dylib in the executable path itself, same error. I've tried using install_name_tool to change the path to the dylib in the executable, nothing changes, same error. I've tried building the test application with -headerpad_max_install_names and then using install_name_tool to change the path. Still nothing changes. Same error.
Is what I'm trying to do not possible with the Mac operating system? I'm new to this platform, and am used to things like this working without a hitch on Windows and GNU/Linux. Also, I'm trying to do all this with the command line. I would very much prefer to avoid XCode.
Edit: Oops, I derped. Turns out I made a typo in my install_name_tool arguments. It's working fine now.
install_name_tool is the right tool.
Try otool your_binary to see which dylib are missing.
Also be sure your binary and the linked library are build for the same architectures.
You'll need to ensure that DYLD_LIBRARY_PATH includes the directory where your library resides.
DYLD_LIBRARY_PATH
This is a colon separated list of directories that contain libraries. The dynamic linker searches these directo-
ries before it searches the default locations for libraries. It allows you to test new versions of existing
libraries.
For each library that a program uses, the dynamic linker looks for it in each directory in DYLD_LIBRARY_PATH in
turn. If it still can't find the library, it then searches DYLD_FALLBACK_FRAMEWORK_PATH and DYLD_FALL-
BACK_LIBRARY_PATH in turn.
Use the -L option to otool(1). to discover the frameworks and shared libraries that the executable is linked
against.
The various details of dynamic linking are documented in the dyld man page.