I'm trying to use liboauth with a C program, using gcc as my compiler, and no matter what I've tried I keep getting the error "ld: library not found for -loauth" and "clang: error: linker command failed with exit code 1".
I'm including the header via "#include <oauth.h>", and my most-recent call to gcc looked like this:
gcc -Wall -lcurl -loauth -I /usr/local/include -v -o api api.c
Now, oauth.h does exist in /usr/local/include, and there are a handful of liboauth files (including liboauth.a) located in /usr/local/bin, which I'm assuming were placed there when I ran the install. I will admit that I'm not very familiar with gcc and compiling non-trivial C programs, but I was able to get libcurl working on a fresh download in just a few minutes. I just can't figure out what's going on with liboauth.
Thanks in advance
If you are sure liboauth's located in /usr/local/bin use
gcc -Wall -L/usr/local/bin -I /usr/local/include -v -o api api.c -lcurl -loauth
It'd also be better to place libraries in the end of the command as there is some important stuff with them (they may depend on each other, etc).
By the way, it's pretty strange your libraries are in /usr/local/bin as libraries are almost always stored in some path like /usr/*/lib.
Related
I have a file called "speed.c" which I wish to use for a web program
This works:
gcc speed.c -lcrypto -lssl
But this doesn't:
emcc speed.c -v -lcrypto -lssl -s EXPORTED_FUNCTIONS=_speed,_main -o speed.wasm
The function within speed.c is called "speed".
On the website for Emscripten, it says that the compiler is just like any other so this one confuses me.
Any help? Thanks!
Emscripten can't use you system's libraries. This is because they are binaries compiled for your own machine (probably 64-bit linux), while emcc compiles to WebAssembly/JavaScript. You can generally see what architecture a binary is targeting with file:
$ file `realpath /usr/lib/libssl.so`
Thus, you will need to first compile OpenSSL with emcc. I haven't done this myself, but I believe it's possible. You could check out this github issue.
Once you've done that you should have two files name libssl.a and libcrypto.a. Then you can compile your own project like this:
$ SSL=/path/to/openssl
$ emcc speed.c $SSL/libssl.a $SSL/libcrypto.a -I $SSL/include/ # etc.
Take a look at the project building page if you haven't yet.
I'm running a Debian (Buster) container and my goal is to compile a small program I wrote which relies on libgit2. First, I was installing libgit2 via the libgit2-dev package and my Makefile had the following:
gcc -O2 -fpic -shared -I /usr/local/include -lgit2 -o output.so my_app.c
However, I'd rather have a "cleaner" environment and install libgit2 via the libgit-27 which, AFAIK, only installs the shared object binary instead of also including the development files like libgit2-dev does.
Using find I can find where the .so file is installed into:
$ find / -name "*git2*" -print 2>/dev/null
/usr/lib/x86_64-linux-gnu/libgit2.so.0.27.7
/usr/lib/x86_64-linux-gnu/libgit2.so.27
/usr/share/doc/libgit2-27
/var/lib/dpkg/info/libgit2-27:amd64.list
/var/lib/dpkg/info/libgit2-27:amd64.symbols
/var/lib/dpkg/info/libgit2-27:amd64.md5sums
/var/lib/dpkg/info/libgit2-27:amd64.shlibs
/var/lib/dpkg/info/libgit2-27:amd64.triggers
and I've been trying several combinations of linking this .so with gcc like:
gcc -O2 -fpic -shared -L /usr/lib/x86_64-linux-gnu/ -libgit2.so.27 -o output.so my_app.c
but so far I always get the following error:
my_app.c:1:10: fatal error: git2.h: No such file or directory
#include <git2.h>
^~~~~~~~
compilation terminated.
I understand this is a glaring lack of knowledge on how C compilation works. My two questions are:
Is it possible to compile my program by just relying on the libgit2-27 Debian Buster package instead of libgit2-dev? If not, why?
If yes, an example and explanation would be appreciated!
I wanted to configure an autotooled project to invoke a non-standard
linker (the gold linker),
using the stock autotools of Linux Mint 16/Ubuntu 13.10
I believed I would achieve this by:
libtoolize-ing the project
Running ./configure LD=/path/to/my/linker ... etc.
However this has been ineffective. libtoolize has been successful. After
a standard ./configure; make I now see that libtool is doing the
linking:
/bin/bash ./libtool --tag=CXX --mode=link g++ -g -O2 -o helloworld helloworld.o
But passing LD=/path/to/my/linker to configure makes no difference. Experimentally,
I even ran:
./configure LD=/does/not/exist
expecting to provoke an error, but I didn't. The output contains:
checking if the linker (/does/not/exist -m elf_x86_64) is GNU ld... no
checking whether the g++ linker (/does/not/exist -m elf_x86_64) supports shared libraries... yes
And thereafter a make continues to link, successfully, invoking g++ exactly as before.
What is the right way to configure a non-standard linker?
But passing LD=/path/to/my/linker to configure makes no difference
This is because LD is almost never and should almost never be used to link any user-space program. Correct links are performed by using the appropriate compiler driver (gcc, g++, etc) instead.
What is the right way to configure a non-standard linker?
If you have /some/path/ld and you want gcc to use that ld, pass -B/some/path flag to gcc.
It then follows that you likely want:
./configure CC='gcc -B/some/path' CXX='g++ -B/some/path' ...
I landed on this via a Google search, though my scenario is a bit different from yours; there was no libtool involved. An old open source program's Makefile was hard-coding ld to create an object file with a symbol from binary data.
This is what I ended up doing to work around the lack of $(LD) being recognized when passed to configure:
https://github.com/turboencabulator/tuxnes/commit/bab2747b175ee7f2fc3d9afb28d69d82db054b5e
Basically I added to configure.ac:
AC_CHECK_TOOL([LD], [ld])
Leaving this answer here for if someone else lands via a google search.
I was searching for a way to create mocking objects with c-code until I stumbled upon cmockery.
For me it seems to be the best mocking software available since it doesn't have a lot of dependencies.
I'm working in ubuntu and downloaded the tarball cmockery from https://code.google.com/p/cmockery/downloads/list
I ran the ./configure, make and make install.
I am able to execute the given examples but I just can't figure out how to get it working on my own projects. I had a look at the configure and makefile to try and find out how they did it, but that was no success. I think it's the linking that's causing my problems.
Files of cmockery can be find at:
/usr/local/include/google/cmockery.h
/usr/local/lib/libcmockery.la
/usr/local/lib/libcmockery.a
/usr/local/lib/libcmockery.so.0.0.0
/usr/local/lib/libcmockery.so.0
/usr/local/lib/libcmockery.so
I tried copying the example files calculator.c and calculater_test.c to a separate directory and compile them there.
This is what I did:
gcc -c -o calculator.o calculator.c
gcc -c -o calculator_test.o calculator_test.c -I /usr/local/include/google/
gcc -o run *.o -L /usr/local/lib/
At the last step I got a lot of undefined references to all functions specific to cmockery and the error:
collect2: error: ld returned 1 exit status
I guess I'm messing things up with the linker but I can't find anywhere how it should be done correctly.
You are missing -lcmockery:
gcc -o run *.o -L /usr/local/lib/ -lcmockery
I'm trying to compile the following project on a remote server.
I've git cloned the project on a folder called 'scode'.
The project requires glib2 and gsl libraries. Since I'm trying to compile on a remote server, I do not have sudo privileges. So I can't use a tool to install glib2 and gsl for me.
As a result, I've manually compiled both gsl and gslib2 under the folders 'scode/gsl' and 'scode/glib'.
I've had to modify the Makefile and add absolute paths to these directories as -I options.
Nonetheless, when I try to compile the final executable. I get the following error:
[dyuret#psglogin scode]$ make
gcc -O3 -D_GNU_SOURCE -Wall -std=c99 -I. -I /home-2/dyuret/scode/gsl
-I /home-2/dyuret/scode/glib/ pkg-config --cflags glib-2.0 scode.o svec.o pkg-config --libs glib-2.0 -lm -lgsl -lgslcblas -o scode
//home-2/dyuret/scode/glib/glib/libglib-2.0.la: file not recognized:
File format not recognized
collect2: error: ld returned 1 exit status make: * [scode] Error 1
I've researched the issue a bit. This link looks informative but I can't quite decipher what the author is saying, as I'm not that experienced with compilers, libtools and the compilation flow in general.
Any help would be much appreciated. I've already spent some time on this issue and I haven't been able to make much progress.
It sounds as if what you did in order to compile the libraries in non-default (i.e. non-system) locations was maybe wrong.
For packages using autoconf (i.e. that have a configure script in the source root) you're supposed to use the --prefix option to ./configure to set the target location where you want the package installed.
With packages building shared libraries, it's often essential to do the make install step, which it sounds as if you maybe didn't do.
Sorry for being vague, these things are a bit complicated.
Someone at my group helped me with the problem. Here're the steps he roughly carried out:
(1) Manually installed glib and additional libraries at $HOME directory - i.e. $HOME/lib, $HOME/include.
(1.1) I think he did this by './configure prefix=$HOME', 'make', 'make install'.
(2) Got rid of `pkg_config` usage, which was causing the problem I outlined originally. Here are his new CLFAGS and LIBS variables:
CFLAGS=-O3 -D_GNU_SOURCE -Wall -std=c99 -I. -I$$HOME/include -I$$HOME/include/glib-2.0 -I$$HOME/lib/glib-2.0/include
LIBS=-lglib-2.0 -lm -lgsl -lgslcblas -L$$HOME/lib -L/usr/local/cuda/lib64 -lcudart
After this, the code compiled without additional problems.