I'd like to install a third-party C library (http://cgm.cs.mcgill.ca/~avis/C/lrs.html) on a Mac OS X. However, the binaries won't seem to install on a Mac OS X (10.9.5). The library is intended for Unix/Linux platforms.
Here are a couple example of errors I get when trying to install the make file. First, here's the error when running make all out of the box (for some reason, running make all64 does nothing):
ld: library not found for -lgmp
I installed the GMP library (https://gmplib.org/) via MacPorts in /opt/local. However, the library does not appear to be found:
cc 2nash-GMP.o -L. -llrsgmp -L/opt/local/include -lgmp -o 2nash
ld: library not found for -lgmp
clang: error: linker command failed with exit code 1 (use -v to see invocation)
make: *** [2nash] Error 1
rm 2nash-GMP.o
How can I get around all this and install on a Mac?
I'll mention that I intend to call a function from this C library many, many times within functions from some (Matlab) code I've written. I'd prefer any potential solution to allow for this.
Update #1:
I've since done the following:
In the makefile, changed LIBDIR from /usr/lib to /opt/local/lib
In the makefile, changed INCLUDEDIR from /usr/include to /opt/local/include
Copied gmp.h file from /opt/local/include to /usr/include
In the makefile, changed RANLIB ?= /bin/true to RANLIB ?= /usr/bin/true
Now, when I run make all, I get the following message:
make: Nothing to be done for `all'.
What other steps should be taken?
I think you would, instead, want something like:
cc 2nash-GMP.o -L. -llrsgmp -I/opt/local/include -L/opt/local/lib -lgmp -o 2nash
The -I option specifies a path to headers to include. The -L option specifies a path to library files to include.
Change the variable LIBDIR in the makefile to the location where the libraries are installed, e.g.:
LIBDIR = /opt/local/lib
Related
I am working on code have Zlib.h header, This header is found in my code folder, I compile this code by using
gcc -o x xx.c -lz
but I get on this
/usr/bin/ld: cannot find -lz
collect2: error: ld returned 1 exit status
This happen just with Linux that I installed in a VBox.
How to fix that.
Try installing 'zlib1g-dev'. On Ubuntu this following command will install the library.
sudo apt install zlib1g-dev
When you type gcc foo.c, you ask gcc to compile and link the given file.
1. Compilation
Compilation consist of transforming the source file into an object file.
This step need the included files, like zlib.h to be found by gcc.
This step seems to be correct on system.
NB: You can ask gcc to only do this step typing gcc -c foo.c, or better gcc -Wall -c foo.c
2. Link
Once the object files have be created, then need to be linked to create an executable file.
It's that step that failed for you: your linked can't find the already compiled functions needed by your code.
When linking with option -lz, you tell your linker "search for libz.so file to find the missing functions"
On current linux distribution, you can install package like libz-dev to install the .so file in well known places. (/lib, /usr/lib, /usr/local/lib...)
If you don't have the libz.so file installed on the library search path, you can specify where is the library to your linker.
For instance, if libz.so is if /bar/baz directory, you can type gcc foo.c /bar/baz/libz.so. The same for libz.a.
In any case, you'll need the libz.so file or at least the libz.a file
See also What's the difference between .so, .la and .a library files?
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 have the following folder on my git repo - https://github.com/ryu577/base/tree/master/numerical/c/NumericalRecipiesCode/lib
On my windows machine which has cygwin installed, I can run make in that directory, which triggers the command -
gcc -o ../bin/lib/tst_libfns ../obj/nrutil.o ../obj/fileio.o ../obj/tst_libfns.o -I ../include -lm
This puts the tst_libfns.o and fileio.o in the obj directory.
Now, I pulled this repository into my ubuntu machine and tried the same thing. However, when the same command is generated there, it gives me the following error:
gcc -o ../bin/lib/tst_libfns ../obj/nrutil.o ../obj/fileio.o ../obj/tst_libfns.o -I../include -lm
../obj/fileio.o:fileio.c:(.text+0x52): undefined reference to `__getreent'
../obj/tst_libfns.o:tst_libfns.c:(.text+0x10): undefined reference to `__main'
collect2: error: ld returned 1 exit status
make: *** [../bin/lib/tst_libfns] Error 1
Am I missing something obvious?
I just figured it out. I had pulled in the .o files through git in the obj directory and gcc was somehow trying to use the existing files (which had been generated in Cygwin + Windows). Somehow, those .o files don't seem to be compatible with linux. When I delete them and run the make command again, the .o files are re-generated. I guess the moral of the story here is that binaries and executables generated by GCC in Windows are incompatible with Linux (and I'll guess vice versa).
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.