I am using Windows subsystem for linux for Ubuntu and I am very new to this. I am trying to build the program (AutoDock Vina) from its source code provided on GitHub - GitHub Link.
In its installation procedure - provided here, it's mentioned that - To compile the binary (you might need to customize the Makefile by setting the paths to the Boost library)
Makefile has the following code written in it -
BASE=/usr/local
BOOST_VERSION=
BOOST_INCLUDE = $(BASE)/include
C_PLATFORM=-static -pthread
GPP=/usr/bin/g++
C_OPTIONS= -O3 -DNDEBUG -std=c++11
BOOST_LIB_VERSION=
include ../../makefile_common
I had previously installed Boost and SWIG using apt-get command as mentioned in the manual.
sudo apt-get install libboost-all-dev swig
When I tried to find out location of Boost library, I found that at following two places boost related files are there -
/usr/lib/x86_64-linux-gnu/ and
/lib/x86_64-linux-gnu/ (these two folders have many files having names starting with libboost)
/usr/include/boost/ (this appears to be main folder for boost)
But, I tried many combinations to the BASE value in Makefile, but in all cases, after building the files, I see the executable named Vina (as expected) is built in the folder but when I try to run the same on terminal, I get command not found error.
Please help me with this - how to find out Boost related values for Makefiles?
Edit 1 - After reading the comment from #MadScientist, I have realized it's not a problem of Boost library but the issue I am facing is because of PATH not set. So I will follow his comment and proceed.
Related
Where can I find the source code and instructions for building libcurl-gnutls.so?
I'm working on a project that needs libcurl-gnutls.so. I am required to build it from source code - I am not allowed to simply install it with "apt-get install libcurl". Unfortunately, my google-fu is failing me and I can't find a source code repository or instructions to build libcurl-gnutls.so anywhere.
Here's what I have found:
Linux-from-scratch has well-documented instructions for building libcurl.so, here: https://www.linuxfromscratch.org/blfs/view/svn/basicnet/curl.html. That lets me build libcurl.so with gnutls, but not libcurl-gnutls.so.
The curl website (curl.se), has detailed instructions on its various options here: https://curl.se/docs/install.html. Those show me how to build libcurl with gnutls, but the end product is still libcurl.so, not libcurl-gnutls.so.
When I run ldd -r on my project, it identifies the functions it needs (curl_easy_init, curl_easy_setopt, curl_easy_perform, and curl_easy_cleanup). I can find those symbols in both libcurl.so and a pre-built libcurl-gnutls.so. This leads me to suspect that libcurl-gnutls.so is libcurl.so, published under a different name. However, renaming libcurl.so to libcurl-gnutls.so is not sufficient to meet the dependency requirements. I could try altering the libcurl project to set its name and version to libcurl-gnutls (not that I know how to do it - I would poke around until I figure it out), but I don't know how appropriate that would be.
I found one other question on Stack Overflow about libcurl-gnutls (How to create lib curl-gnutls.so.4), but the answers to that are to install a pre-built version via apt-get install, which I am not allowed to do.
libcurl-gnutls.so actually just comes from a cURL built with gnutls support. You can find the repository here: https://github.com/curl/curl
Check out the docs/INSTALL.md. It has all the information you need to build cURL, specifically the part about Building from git.
Here is a snippet you might need:
./configure --with-openssl [--with-gnutls --with-wolfssl]
make
make test (optional)
make install
Here's a complete answer cobbled together from everyone's input (Thanks especially to Knud Larsen and Wassim Dhif):
libcurl-gnutls.so is just libcurl.so built with gnutls support. Archives for the project are here: https://curl.se/download
Change the SONAME that libcurl.so is built with by editing ltmain.sh to change:
if test -n "$soname_spec";
then eval soname=\"$soname_spec\"
To:
if test -n "$soname_spec"; then
soname=libcurl-gnutls.so.4
I'm sure there's a more elegant way to do it, but this works and I need to move on.
Alternatively, you can modify the the SONAME after libcurl.so is built with:
patchelf –set-soname libcurl-gnutls.so.4 libcurl.so
Check your client (the program or shared library that requires libcurl-gnutls.so as a dependency), to see if it requires version information.
For instance, when I run objdump -p myprogram, I get this:
Version References:
required from libcurl-gnutls.so.4:
0x0b103d23 0x00 14 CURL_GNUTLS_3
To build libcurl-gnutls.so with this version information:
2a. Set the version information to version 3:
In lib/libcurl.vers.in change:
CURL_#CURL_LT_SHLIB_VERSIONED_FLAVOUR#4
To:
CURL_#CURL_LT_SHLIB_VERSIONED_FLAVOUR#3
2b. Use --enable-versioned-symbols when configuring the libcurl project. This adds the required version information.
./configure --with-gnutls --enable-versioned-symbols [other arguments as needed]
The final product may be named libcurl.so, but can be renamed. It will have its SONAME set to libcurl-gnutls.so.4 and will have the required version information.
If you have an answer for this, or further information, I'd welcome it. I'm following advice from here, to offer some unsolicited help by posting this question then an answer I've already found for it.
I have a bare-metal ARM board for which I'm building a cross-toolchain, from sources for GNU binutils, gcc and gdb, and for SourceWare's Newlib. I got those four working and cross-built a DoNothing.c into an ELF file - but I couldn't disassemble it with this:
$ arm-none-eabi-objdump -S DoNothing.elf
The error was:
$ arm-none-eabi-objdump: error while loading shared libraries: libdebuginfod.so.1: cannot open shared object file: No such file or directory
I'll follow up with a solution.
The error was correct - my system didn't have libdebuginfod.so.1 installed - but I have another cross-binutils, installed from binary for a different target, and its objdump -S works fine on the same host. Why would one build of objdump complain about missing that shared library, when clearly not all builds of objdump need it?
First I tried rebuilding cross binutils, specifying --without-debuginfod as a configure option. No change, which seems odd: surely that should build tools that not only don't use debuginfod but which don't depend on it in any way. (If someone can answer that, or point out what I've misunderstood, it may help people.)
Next I figured debuginfod was inescapable (for my cross-tools built from source at least), so I'd install it to get rid of the error. It's a component of the elfutils package, but installing the latest elfutils available for my Ubuntu 20.04 system didn't bring libdebuginfod.so.1 with it.
I found a later one, for Arch Linux, whose package contents suggested it would - but its package format doesn't match Ubuntu's and installing it was going to involve a lot of work. Instead I opted to build it from the Arch Linux source package. However, running ./configure on that gave a couple of infuriatingly similar errors:
configure: checking libdebuginfod dependencies, --disable-libdebuginfod or --enable-libdebuginfo=dummy to skip
...
configure: error: dependencies not found, use --disable-libdebuginfod to disable or --enable-libdebuginfod=dummy to build a (bootstrap) dummy library.
No combination of those suggestions would allow configure for elfutils-0.182 to run to completion.
The problem of course was my own lack of understanding. The solution came from the Linux From Scratch project: what worked was to issue configure with both of the suggested options, like this:
$ ./configure --prefix=/usr \
--disable-debuginfod \
--enable-libdebuginfod=dummy \
--libdir=/lib
That gave a clean configure; make worked first time, as did make check and then sudo make install which of course installed libdebuginfod.so.1 as required. I then had an arm-none-eabi-objdump which disassembles cross-compiled ELF files without complaining.
I am trying to install the Vision Workbench on my computer, following the instructions from this homepage: http://lunokhod.org/?p=13. I have installed all dependencies but I have libboost1.54-all-dev instead since I am using Mint 17 (Ubuntu 14.4).
After that I have created the config.options file I do ./autogen and ./configure.
However, I get the following in the logfile:
configure:20861: /usr/include/boost is missing these required libraries: BOOST_PROGRAM_OPTIONS BOOST_FILESYSTEM BOOST_THREAD
Checking for a boost in /usr/include/boost-*
Checking for a boost in /usr/local/cuda/include
Checking for a boost in /usr/local/cuda/include/boost-*
configure:20875: checking for package BOOST
HAVE_PKG_BOOST=no
However, in /usr/include/boost/ I have booth program_options, filesystem and thread.
The .so files are under /usr/lib/x86_64-linux-gnu/ for opencv, boost and flann, but somehow it can only find flann.
Does anyone have an idea about where the error might be?
EDIT: In the log-file I saw that the program looked for cxcore when it searched for opencv, but in the new version it is called opencv_core so I did a symbolic link from cxcore to opencv_core and then ./configure finds opencv. However, boost is still a problem and is necessary to build the program.
EDIT2:
I have now downloaded an earlier version of boost (1.42), and almost all boost programs are found except BOOST_THREAD. When I install the boost library I get the following messages:
error: #error "Threading support unavaliable: it has been explicitly disabled with BOOST_DISABLE_THREADS"
/ Erik
try running
./configure --with-boost="path/to/boost"
if you have more than one version of boost installed, you may need to also set environment variables
HAVE_PKG_BOOST=yes
PKG_BOOST_CPPFLAGS=/path/to/boost
PKG_BOOST_LDFLAGS=/path/to/boost
I created a shared library, libsslab_core.so.1.0.0 using gcc with proper options. I am pretty sure that the shared library works because I already linked it to another source code (I explicitly tells a compiler, gcc, the location of the library using -l option of the compiler).
After testing the library works, I tried to integrate the library into my Linux machine. I went to the /etc/ld.so.conf.d/ and added a file, sslab.conf. In the file I just typed the absolute path of the library, /opt/lib/sslab. Next, I executed ldconfig as a root to update the cache file of ldconfig. And I checked if the system finds the newly added library by typing ldconfig -p | grep libsslab. My Linux machine found the library, so I thought everything is finished.
However, when I try to compile a source code using the library, it gives me the following error:
/usr/bin/ld: cannot find -lsslab_core
When I move the library to /usr/local/lib, update the content of sslab.conf, and execute ldconfig as a root. I can use the shared library without any problems.
Do you have any ideas about the problem that I've come across on Ubuntu 12.04?
For your information, I refer to a document in TLDP to generate my own shared library. Here is the link: http://www.tldp.org/HOWTO/Program-Library-HOWTO/
I compiled the MongoDB C Drivers successfully and run the test scripts also but I am not able to compile the scripts which I am writing myself.
Following is the command and its error output.
$ gcc -Isrc --std=c99 ./src/*.c -I ./src/ tutorial.c -o tutorial -D_POSIX_C_SOURCE=200112L
./src/env_win32.c:27:53: fatal error: ws2tcpip.h: No such file or directory
compilation terminated.
I found that there is no file name ws2tcpip.h in /usr/include directory
Take out the ./src/*.c, that tells gcc to compile all of the c programs in the /src directory which includes some windows only programs.
What worked for me was to tell gcc to include the libmongoc.so that was built when the drivers were built.
The following command worked for me. My drivers are in directory "mongo-c-driver".
gcc --std=c99 -I mongo-c-driver/src -o tutorial tutorial.c mongo-c-driver/libmongoc.so
In my opinion the mongodb C API documentation is a little buggy in this area. Also, the latest header files don't match the source code shown in the tutorial. For example mongo-insert requires 4 parameters in the v0.6 headers, but the tutorial shows only 2 parameters.
In researching this problem and trying to recreate it by installing mongoDB and the C driver myself I have discovered that v0.6 of the driver broke compatibility with previous version of the API by adding support for write_concern which adds a 4th parameter to the mongo_insert function (which can be set to null). The example.c program provided in the docs/examples directory does not compile in v0.6. This bug is documented in patch CDRIVER-157 in github for the c-driver.