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.
Related
first of all: I am fairly new to the C- section. So please dont roast but rather help me understanding, if I got something wrong. Thank you in advance.
So...
I do have a big problem which doesn't seem to be found anywhere in the extend that I need it to be solved.
My standpoint: I want to read and directly direct a keyboard- input to a specific function.
NCurses has been mentioned a hundredfold and I thought like: Well yes, that looks promising.
I find many tutorials on how to implement non-standard libraries into the VisualStudio environment, but all of them seem to require following files: *.dll, *.lib, *.h.
Seems legit. I also found, that *.a seems to be a "static library", so it seems I may be able to use the *.a instead of the *.lib files.
Now, when I go on and download the latest ncurses (6.1, ftp://ftp.gnu.org/gnu/ncurses/), I dont find any of the *.h and *.lib, nor *.dll files. In addition to that, I honestly dont even know, which of those files are crucial to implement for the most basic functions of ncurses.
No matter how long I search, either they show me a ncurses version, which has already "pre- built" *.lib- files, etc., or they explain it with the terminal/console (which I dont need nor understand, cause I use VS2017).
I hope you understand where I('m) s(t)uck at and hope that you can help me.
Also, if I asked this question although it already exists, I'm sorry, but I couldnt find any of this questioning in this specific case.
For GNU, you can use the termcaps for reading.
When you compile the file you have to link the libraries curse
Cmake:
add_executable(${NAME} ${SRCS} ${HEADERS})
find_package(Curses REQUIRED)
include_directories(${CURSES_INCLUDE_DIR})
target_link_libraries(${NAME} libft ${CURSES_LIBRARIES})
Commande line:
gcc main.c -I header.h -lncurses
So maybe you have somewhere in vs a way to edit compilations flag. Here you have to add -lncurses has a compilation command flag.
If librairies still not found, maybe you have to install it
sudo apt-get install libncurses5
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'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 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.)
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.