I have a project that links to libssl.so and I'm hitting a bug in libssl and never versions of the lib fixes it. However on the system I'm working I don't have root account so I've built libssl and prerequirements myself under $HOME/opt.
Now, when I'm doing:
./configure --prefix=`$HOME/opt`
make
the build system still uses the older system-wide version of libssl.
I'm trying to find the proper way to "hack" autotools to link with libs I've compiled.
I'm not sure, but perhaps you should also add the new path to the PKG_CONFIG_PATH. That is, if your project uses PKG_CHECK_MODULES for finding libssl.
There's always ./configure LDFLAGS=-L$HOME/opt/lib CPPFLAGS=-I$HOME/opt/include. But that method globally uses headers from that prefix and globally links against libs located there.
Many projects provide AC_ARG_WITHs to allow to customise paths, e.g.
AC_ARG_WITH([ssl], ...)
or
AC_ARG_WITH([ssl-prefix], ...)
AC_ARG_WITH([ssl-libs], ...)
AC_ARG_WITH([ssl-includes], ...)
in analogy to autoconf's --x-includes and --x-libraries
But I guess it's a question of personal taste.
Just noticed you don't want to change your files, in that case you could just add the library in question to the the LIBS variable, or use an rpath:
./configure LIBS="$HOME/opt/lib/libssl.so.x.y.z"
or
./configure LDFLAGS="-Wl,-rpath,$HOME/opt/lib/"
It seems that:
LDFLAGS="-L$HOME/opt/lib" ../configure --prefix="$HOME/opt"
is forcing autotools to try $HOME/opt/lib first. If anybody knows better or more general answer I'm still all ears.
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 trying to have a scheme with my library that is coherent and usable/reusable.
I work in a team where we work with continuous integration but sometimes I need to use old version of the same library. That's because some part of the software are not updated for using the new version.
I'm actually in the middle of a headache understanding how to use cmake for having something like this:
PATH/Library/Processor/Library_X/Version/static_library_and_includes
Where Library is a common name where to put my stuff
Processor could be attiny24, atmega, lxpXXXX, etc
Library_X is the name of the library
Version a progressive number from 0 to X
static_library_and_includes the static libraries built within that cmake module and the include files needed for using it.
How can I do this using cmake?
I work with different microprocessor crosscompiling with gcc. This is not a problem.
I work with static library, this is not a problem.
I can install them in the right directory. Not a problem
I can't ask the executable to link to the right .a file. Sometimes cmake pick the right one, sometimes not.
Can you please give me a hint on how you guys do it?
thank in advance
Andrea
See the search paths here: https://cmake.org/cmake/help/latest/command/find_package.html#search-procedure .
CMake will find packages in directories named name*, so you can install to <prefix>/FizzBuzz-1.0.0 and <prefix>/FizzBuzz-2.0.0.
As long as each as a correct ConfigVersion.cmake file, it should do what you want.
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 am working on a system where libraries are installed with libtool (I just discovered libtool) and it seems to be a powerful tool like autotools.
My problem is that I am not able to link my programs using autoconf and automake. After some googling and stackoverflowing, I found how to link my program manually with libtool.
My question is, how to use libtool with autoconf? What are the commands to add in configure.ac and/or Makefile.am? I also found the lazy solution of copying the dependency from the .la file and put it in configure.ac, but I think it is the wrong solution.
I usually work on a system where I have the root permissions, so I am usually lazy and always install many things at system level, and everything always run smoothly until today where I am on a system where I do not have root privileges.
After more googling, I found the solution.
1) Add the macro LT_INIT to configure.ac
LT_INIT(static)
There are many other options, see http://www.gnu.org/software/libtool/manual/html_node/LT_005fINIT.html#LT_005fINIT
2) Add the variable progname_LDADD to Makefile.am
progname_LDADD = library_name.la
where progname is defined in
bin_PROGRAM = progname
There are certainly things that I am missing, but it is working for now. Any suggestion is welcome.
I am working on a multi-platform C program. The makefile has become pretty complicated because of all the different compilers, library locations, etc. on each machine. I figured Autoconf/Automake would be a good solution, though my previous experience using those tools was minimal.
My Makefile.am has the line LIBS=-lX11, but linking fails with the error "/usr/bin/ld: cannot find -lX11". I can work around this by adding "-L/usr/X11R6/lib/" to the definition of LIBS, but should I really need to do that? When I run ./configure, it says:
checking for X... libraries /usr/X11R6/lib, headers /usr/X11R6/include
So it seems like Automake should know where to find it. Is there a way I can reference its location in Makefile.am without having to hardcode it, since the X11 libs will be in a different place on each machine?
Your Makefile.am should not set LIBS. If you need to link with a library, configure.ac should include a check for the library and the configure script will set LIBS accordingly. Also, Makefile.am should not specify paths to libraries. Each system should be configured so that the precompiler can find the headers and the linker can find the libraries. If the system is not set up so that the linker can find a library, the correct solution is for the user to specify the location in LDFLAGS rather than hard coding something in Makefile.am. (eg, rather than adding -L/p/a/t/h to a Makefile, you should add LDFLAGS=-L/p/a/t/h to the invocation of configure.)