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!
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 am trying to use a grsecurity gcc plugin that I found on their unofficial linux kernel source tree (the respectre_plugin/ one).
My GCC version is 4.7, I modified scripts/gcc-plugins/Makefile to make it compile the plugin, and I built it with the root Makefile using make gcc-plugins, that shows no error.
Then, when I try to compile a C file that has a Spectre-like flaw, I got the following build error:
file.c:36:31: error: array_index_mask_nospec is not defined
This function is defined in respectre_plugin/respectre_plugin.c, and I have no idea why I've got this strange build error, if anyone knows about it...
My build invocation is the following:
gcc -Wall -Wextra -std=c99 -fplugin=/path/to/respectre_plugin.so -c file.c -o file.o
Thanks for any help !
I am trying to compile Apache Lucy. Here are the steps I followed:
Downloaded Lucy and Clownfish
Compiled Clownfish runtime and compiler
Configured Lucy
Started Lucy Make
The compilation of the files in the core directory works fine but when it gets to the modules it throws an error:
$ make
gcc -pedantic -Wall -Wextra -Wno-variadic-macros -std=gnu99 -D_GNU_SOURCE -D CFP_LUCY -D CFP_TESTLUCY -fvisibility=hidden -O2 -g -fno-strict-aliasing -fPIC -I . -I ../core -I autogen/include -I ../modules/analysis/snowstem/source/include -I ../modules/unicode/ucd -I ../modules/unicode/utf8proc -c ../modules/analysis/snowstem/source/libstemmer/libstemmer_utf8.c -o ../modules/analysis/snowstem/source/libstemmer/libstemmer_utf8.o
../modules/analysis/snowstem/source/libstemmer/libstemmer_utf8.c:4:35: fatal error: ../include/libstemmer.h: No such file or directory
#include "../include/libstemmer.h"
^
compilation terminated.
make: *** [../modules/analysis/snowstem/source/libstemmer/libstemmer_utf8.o] Error 1
The problem seems to be that the code files in the modules include the include files with a relative path like #include "../include/libstemmer.h". Even though the resulting directory is included in the include files directory i.e. -I ../modules/analysis/snowstem/source/include but it does not work
I started modifying the source files to remove the relative path but more started cropping up. I think there must be a better way. Any help on how I can fix this would be really helpful.
If you do only cpan Lucy::Simple it should be enough
It seems to me there is not a C library available yet.
Above link is old (2012) but explains why it is not obvious.
http://grokbase.com/t/lucy/user/12bp9rw0g7/lucy-user-using-lucy-directly-from-c
https://github.com/cancerberoSgx/lucy.js/blob/master/scripts/build-lucy-c.sh
that's a shell script that will clone lucy .git and dependencies, compile lucy c and clownfish C them and then compile and run one of the lucy/samples/c
It does it all locally in a folder, so you don't have to install anything globally as root. you need linux buildtools like gcc, make, configure, etc. Good luck
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.
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.