I'm writing a simple C program that uses the TagLib library. I had originally installed the library in /usr/local and compiled and linked my program against it. I've since removed the library completely and am attempting to link against a compiled version of the library in another location. The problem is when I compile my program now, it compiles cleanly, but when attempting to run it, my program is looking for the library that used to exist in /usr/local/lib instead of the new location. For example, my code and the new TagLib library is in /Users/mdi/Code/tag.
I'm compiling my program like this:
cc main.c -Wall -I./taglib/bindings/c -o tag -L./taglib/bindings/c/.libs -ltag_c
Like I said, the compile completes with no errors or warnings. But when attempting to run the binary, I get this error:
dyld: Library not loaded: /usr/local/lib/libtag_c.0.dylib
Referenced from: /Users/mdi/Code/tag/./tag
Reason: image not found
Trace/BPT trap
Running 'otool -L' on the binary shows this:
tag:
/usr/local/lib/libtag_c.0.dylib (compatibility version 1.0.0, current version 1.0.0)
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 125.2.1)
Why is it still trying to use the TagLib library that no longer even exists in /usr/local/lib and more importantly, how do I fix this?
I don't develop on Mac, but I believe your problem is that your library isn't located in your default dynamic link path. It varies on platform, but /usr/local/lib is a common one amongst them, and that's why it's showing up as the path your linking with at runtime.
You can change your default search path for shard libraries, but I'm uncertain of how to do this on a Mac. You should also be able to set the environment variable DYLD_LIBRARY_PATH within your session to force dyld to search other directories before searching the default directories.
%> export DYLD_LIBRARY_PATH=/path/to/your/library:$DYLD_LIBRARY_PATH
Adding directories to your default search path at a system level is better than the environment variable solution above, but I'm unaware of how to do this on the Mac.
Edit:
After a little searching, I found this link that you'll likely find helpful.
First, are you sure there are no dangling symlinks in /usr/local/bin ? Then, I don't know how that library is compiled/linked so I can't tell you how to do this, but you can try adding the -rpath linker option. For example:
gcc -o libtag_c.0.dylib ... -Wl,-rpath,/Users/mdi/Code/tag
That option adds an explicit search path for the library and the runtime linker will then search at that path for the library.
Thanks for the help guys. Actually, unfortunately neither of these solutions worked. After more digging around, I noticed that the newly built libs were getting the old path as well, as reported by 'otool -L'. I managed to fix this by using install_name_tool -id /new/path/to/lib newly_built_lib on the libs after they were already built.
This seems to fix the problem, but I'm still curious as to why this old path to the lib is still hanging around even after it has been completely removed (no dangling symlinks). I also tried sudo update_dyld_shared_cache -force without success. But thanks for the help anyway.
Related
The title states the problem statement: I'm trying to create a CMake project utilizing the libwebsocket library, but I can't find any information for doing so.
Is there anyone who have tried this? A simple CMakeLists.txt for e.g. the test-server program would be much appreciated!
I've compiled and installed the library on my Ubuntu 14.04 machine.
EDIT: I would also like to know if anyone has experience in using the libwebsocket lib w/ C++?
EDIT 2:
After using #evadeflow's answer I'm able to run cmake and build the project. However now I get the following runtime error:
And here's an ls of the /usr/local/lib/ folder
It seems like the libwebsockets.so.7 file is not found?
From CMake:
${LIB_WEBSOCKETS_INCLUDE_DIRS} = /usr/local/lib
${LIB_WEBSOCKETS_INSTALL_DIR} = /usr/local
EDIT 3:
Solved edit 2 by:
Editing the file /etc/ld.so.conf and add /usr/local/lib.
Reference: https://lonesysadmin.net/2013/02/22/error-while-loading-shared-libraries-cannot-open-shared-object-file/
If you've already installed libwebsockets, something like this ought to work:
cmake_minimum_required(VERSION 2.8)
find_package(PkgConfig)
pkg_check_modules(LIB_WEBSOCKETS REQUIRED libwebsockets)
get_filename_component(
LIB_WEBSOCKETS_INSTALL_DIR
${LIB_WEBSOCKETS_LIBRARY_DIRS}
DIRECTORY
)
add_executable(
test-server
test-server/test-server.c
test-server/test-server-http.c
test-server/test-server-dumb-increment.c
test-server/test-server-mirror.c
test-server/test-server-status.c
test-server/test-server-echogen.c
)
target_link_libraries(
test-server
${LIB_WEBSOCKETS_LIBRARIES}
)
set_target_properties(
test-server
PROPERTIES
INCLUDE_DIRECTORIES
${LIB_WEBSOCKETS_INCLUDE_DIRS}
LINK_FLAGS
"-L${LIB_WEBSOCKETS_LIBRARY_DIRS}"
COMPILE_DEFINITIONS
INSTALL_DATADIR="${LIB_WEBSOCKETS_INSTALL_DIR}/share"
)
This is basically a stripped-down version of what's in the CMakeLists.txt file from the libwebsockets github project, without all the platform- and build-specific conditionals.
I hope this is enough to satisfy your request for a 'simple' CMakeLists.txt example. I tested it with CMake version 2.8.12.2; it should work fine as-is if you've installed libwebsockets to its default prefix of /usr/local; however, if you installed to a different location, you will need to set PKG_CONFIG_PATH in the environment from which you invoke cmake.
Also, as explained in the CMake documentation, you will need to replace DIRECTORY with PATH in the get_filename_component() invocation if you're using CMake 2.8.11 or earlier.
UPDATE: Regarding the file not found error from your follow-up comment, this is almost certainly due to libwebsocket.so[.7] not being on the linker's default path. There are at least three ways to fix this, but the easiest way to verify that this is the problem would be to just launch the app from the terminal using:
$ LD_LIBRARY_PATH=/usr/local/lib ./test-server
If it works, you know that was the issue. (Oops—I see you've figured it out in the meantime. Yeah, updating /etc/ld.so.conf is another way. Or, you can force CMake to link to the static version of libwebsockets [as described in this answer] is another. But I like your solution best.)
UPDATE: One thing that wasn't mentioned about /etc/ld.so.conf is that you generally need to run sudo /sbin/ldconfig after editing it in order to update the shared library cache. And—when setting non-default paths for a particular application—many people consider it good form to add a new 'sub-config file' in /etc/ld.so.conf.d rather than edit the global ldconfig file. (For the case of adding /usr/local/lib, though, this is such a common requirement I'd be inclined to dump it in the global config, which is what lots of Linux distros do, anyway.)
I am building a package with CMake (3.0.2). This package relies on boost_python and some others. There is an older version in /usr/lib64 and I have another newer version in my own directory /home/x/opt/boost-1.56/lib. There is an symbol link /home/x/opt/boost-1.56/lib64 to deal with the multi-arch gcc.
However, even if I set BOOST_ROOT=/home/x/opt/boost-1.56/lib, and in CMakeCache.txt there is
//Boost python library (release)
Boost_PYTHON_LIBRARY_RELEASE:FILEPATH=/home/x/opt/boost-1.56/lib/libboost_python.a
The generated link.txt contains such a line, instead of the full path:
-Wl,-Bstatic -lboost_python
And when make, it links to the one under /usr/lib64/, which is wrong.
Question:
How to make CMake to use the full path? As documented, only when libraries under system default folders are dealt with -Bstatic, which should not be my case.
Why -Wl,-Bstatic -lboost_python does not work even I have "/home/x/opt/boost-1.56/lib" in LD_LIBRARY_PATH and LIBRARY_PATH? From my limited knowledge they should override the system default.
Information:
gcc --print-search-dir gives:
/home/x/opt/boost-1.56/lib/x86_64-unknown-linux-gnu/4.9.2/
/home/x/opt/boost-1.56/lib/../lib64/
/lib/x86_64-unknown-linux-gnu/4.9.2/
/lib/../lib64/
/usr/lib/x86_64-unknown-linux-gnu/4.9.2/
/usr/lib/../lib64/
/home/x/opt/boost-1.56/lib/
/lib/
/usr/lib/
set(Boost_NO_SYSTEM_PATHS ON)
This will allow it to ignore everything but BOOST_ROOT
Solution (partially only):
CMake uses -Bstatic if there it thinks that the boost libraries it chooses are in the system path, including that related to enviromental variables. Else it use the full path.
I still cannot find why LIBRARY_PATH cannot override the system
So to make it work, REMOVE everything in LIBRARY_PATH and LD_LIBRARY_PATH will do the trick: CMake will use full path in that case.
Add this at the beginn oingf your top level CMakeLists.txt
cmake_minimum_required(VERSION 3.3)
and use cmake 3.3.0 or later.
Interestingly, with cmake 3.11.1 set(Boost_NO_SYSTEM_PATHS ON) did not work for me.
I've downloaded the portaudio codebase and compiled it fully with source, and installed it to my system with these commands:
./configure
make
sudo make install
But XCode is complaining to me, even when I put -lportaudio in the Other Linker Flags for the project settings.
I've researched this problem and tried whatever I could find on Stack Overflow, but there was no decisive answer that would work for me. Any advice on how to fix this?
I'm using an older version of XCode and haven't bothered looking at how the interface might have changed in the newer versions, but this is generally solved for me by modifying the User Search Paths under your project settings. Look at the screenshot, add /usr/local/include to Header Search Paths and make Always Search User Paths "Yes." That should do the trick
Edit:
One more thing to note, this is only /usr/local/include because that's the default install directory for the portaudio.h file in the portaudio build (as it is with many libraries).
If you have a different prefix other than /usr/local/include, add that instead.
I'm trying to statically link glib into my C program. I'm not sure what's the best way to do this. I downloaded the code and put it in a subdirectory called glib-2.36.4. I added "-Iglib-2.36.4" when using gcc. The glib.h is in the glib-2.36.4/glib directory and in that file there are references to other header files under the glib directory (such as #include ).
I'm not sure why that is since both glib.h and these other header files are at the same level (in glib subdirectory). I got a compile error due to galloca.h not being found (even though it's there). So I copied glib.h up one level and those errors went away. I then got an error about a missing glibconfig.h. I copied that from my usr directory and that error went away. I compiled my project and now I'm getting an error about undefined reference to g_ptr_array_new. I guess this must be because I haven't actually compiled glib. I had tried to build glib, but when I typed "./configure", but I got this message:
checking if arpa/nameser_compat.h is needed... configure: error: could not compile test program either way
I did install glib using yum, but I really want this code to run even if glib is not installed on a machine.
You need to install both glib and glib-dev via yum, compile using ./configure, (take a look in the ./configure script to see if there are any flags you need to supply or defines you need to produce the static build), without moving any files about, and then you need to compile your code using -i path/to/glib/includes and link with -L path/to/built/static/library
I have a collection of dynamic libraries that I want to link to in /usr/local/lib, how can I do this using gcc without setting my LD_LIBRARY_PATH (i have heard it is bad to do this fora number of reasons).
I have spent an hour looking at this on the internet, and fiddling with command line arguments, the only way I got it to work was using the -static -I/usr/local/lib/ flag, but this converts dynamic libraries to static libraries, and the compiler throws up some warnings.
Thanks for your help
Add /usr/local/lib to the loader configuration in /etc/ld.so.conf and run ldconfig.
You can set the system wide search directories for ldd (the dynamic linker) in /etc/ld.so.conf. In many distributions (well, mine) there is a /etc/ld.so.conf.d/ directory, from which the /etc/ld.so.conf includes all *.conf files. You can add the directory directly in ld.so.conf or add a .conf file in the directory.
Of course, you'll need root access to do this.
Oh, yeah: as Ignacio says, run ldconfig after changing these config files.