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
Related
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 am currently following the Bare Bones tutorial from OSDev and i have set up everything and compiled the kernel and bootloader into object files, and i have the .ld file. However, when i try to link the files and produce it into a bin using i686-elf-gcc -T linker.ld -o myos.bin -ffreestanding -O2 -nostdlib boot.o kernel.o -lgcc, i get this error:
.../i686/bin/../lib/gcc/i686-elf/4.8.2/../../../../i686-elf/bin/ld.exe: cannot open linker script file linker.ld
collect2.exe: error: ld returned 1 exit status
I am using GCC and using the compiled version of i686-elf-gcc which includes many more compilers and i have added 4 dlls as it was missing (also not related to linker), but i installed MinGW and added them. I am on Windows 10 x64. Many of the solutions or workarounds i find just brings up more errors or does absolutely nothing to the errors (-T doesn't do anything, -noixemul is not a parameter.). I removed multiboot content since i am gonna use a sector-long bootloader which loads the object files.
If i'm not mistaken, your problem is really, really, really simple:
You don't have access to linker.ld. Try running as superuser or changing the permissions.
If this doesn't solve it, you have an actual problem. Try not using the -T flag.
EDIT: Dear god, I didn't expect this to be right. Thanks!
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.