I'm trying to write a small C application which uses the x264 API, and I'm having problems compiling the code with a link to the x264 libaray.
In the /project/ directory there are two sub-folders:
/project/mycode/ and
/project/x264-snapshot-20120120-2245.
I have installed x264 in the latter subdirectory using ./configure and then 'make'. As such the library I think I want to link to is /project/x264-snapshot-20120120-2245/libx264.a
In /project/mycode/ I have a single source code file (prototype.c), which has the following imports:
#include <stdio.h>
#include <inttypes.h>
#include "../x264-snapshot-20120120-2245/x264_config.h"
#include "../x264-snapshot-20120120-2245/x264.h"
As expected, if I try to compile without linking to the x264 library, I get an error:
/project/mycode: gcc -o prototype prototype.c
/tmp/cc5NwRTp.o: In function `main':
prototype.c:(.text+0x6c): undefined reference to `x264_param_default_preset'
prototype.c:(.text+0xf6): undefined reference to `x264_param_apply_profile'
collect2: ld returned 1 exit status
So I try to link the library I mentioned above, but it isn't found:
/project/mycode: gcc -o prototype prototype.c -I../x264-snapshot-20120120-2245/ -llibx264.a
/usr/bin/ld: cannot find -llibx264.a
collect2: ld returned 1 exit status
I've tried a few variations, like:
gcc -o prototype prototype.c -I../x264-snapshot-20120120-2245/ -l ../x264-snapshot-20120120-2245/libx264.a
gcc -o prototype prototype.c -I../x264-snapshot-20120120-2245/ -llibx264
gcc -I ../x264-snapshot-20120120-2245/ -llibx264.a -o prototype prototype.c
As is probably obvious by now, I'm fairly new to this, so I'm hoping there is an easy solution
For anyone who looks at this in the future, the answer was:
gcc -pthread -o prototype -L../x264-snapshot-20120120-2245/ -lx264 -lm
-L specifies the directory of the library and -l specifies the name of the library, minus the 'lib' prefix and the '.a' suffix. The -lm and -pthread arguments are also needed for the x264 library.
Related
I'm trying to make a relocatable object file with gcc. I use solution from this post. The solution works fine with ld:
$ ld -r a.o b.o -o c.o
However when I try to use it with gcc, the following error happens:
$ gcc -r a.o b.o -o c.o
/usr/bin/ld: cannot find -lgcc_s
/usr/bin/ld: cannot find -lgcc_s
collect2: ld returned 1 exit status
Using the -Wl,-r and -Wl,--relocatable options gives the same result.
Is there any way to link relocatable object file with gcc or I'm forced to use ld for doing this?
To solve this problem, the -nostdlib option must also be passed to gcc:
$ gcc -r -nostdlib a.o b.o -o c.o
I don't know it for sure, but it seems without this option gcc tries to link standard libraries into output relocatable object.
I know this is something so simple I'm going to hate myself for having to ask it, but my head is aching from repeated hits on the desktop. I've read dozens of stackoverflow and google results which suggest that the following should work:
$ ls /usr/local/lib/libusb*
/usr/local/lib/libusb-1.0.a /usr/local/lib/libusb-1.0.so /usr/local/lib/libusb-1.0.so.0.1.0
/usr/local/lib/libusb-1.0.la /usr/local/lib/libusb-1.0.so.0
$ gcc -I ~/libusb-1.0.18/libusb -c test.c
$ gcc -L/usr/local/lib -o test test.o -llibusb
/usr/bin/ld: cannot find -llibusb
collect2: error: ld returned 1 exit status
$ gcc -L/usr/local/lib -o test test.o -llibusb-1.0
/usr/bin/ld: cannot find -llibusb-1.0
collect2: error: ld returned 1 exit status
Why is that not correct? One of those should have worked and I've tried many, many more variations.
For completeness I'm running Ubuntu 14.04 (fresh VM installation).
I built libusb from source (~/libusb-1.0.18) with:
./configure --disable-udev
make
sudo make install
The leading lib and trailing .so are automatically filled in by the linker, so you should not specify either on the command line. Your command should be:
gcc -L/usr/local/lib -o test test.o -lusb-1.0
I have searched high and low for answer to this issue. I am using boost 1.48 and the program is extremely simple, since I have broken it down to its simplest form in order to solve this issue.
#include <boost/filesystem.hpp>
int main(int argc, char **argv) {
return 0;
}
The g++ command executed from my Makefile is as follows:
g++ -m32 -Wall -o mapnik-test -L/usr/lib -I/usr/include -I/usr/include/freetype2 -lpthread -lboost_system mapnik-test.cpp
The complete list of errors during linking is as follows:
/tmp/ccIbmuee.o: In function `__static_initialization_and_destruction_0(int, int)':
mapnik-test.cpp:(.text+0x49): undefined reference to `boost::system::generic_category()'
mapnik-test.cpp:(.text+0x53): undefined reference to `boost::system::generic_category()'
mapnik-test.cpp:(.text+0x5d): undefined reference to `boost::system::system_category()'
collect2: ld returned 1 exit status
make: *** [mapnik-test] Error 1
I have found many people suffering from the same issue, but in most cases, the solution has been to provide the boost_system library in the LDFLAGS. As you can see from the g++ command line, I already have this specified. I have even tried explicitly linking against the libboost_system.a library to no avail. Am I the only person with this complaint?
Put the source file at the beginning of the command line.
Try
g++ -m32 -Wall mapnik-test.cpp -o mapnik-test -L/usr/lib -I/usr/include -I/usr/include/freetype2 -lpthread -lboost_system
The libraries should be specified only after the source file so that the linker can resolve the undefined references in the source file.
I am observing a difference when trying to do the same operation on GCC 4.4 and GCC 4.5. Because the code I am doing this with is proprietary, I am unable to provide it, but I am observing a similar failure with this simple test case.
What I am basically trying to do is have one shared library (libb) depend on another shared library (liba). When loading libb, I assume that liba should be loaded as well - even though libb is not necessarily using the symbols in liba.
What I am observing is when I compile with GCC 4.4, I observe that the liba is loaded, but if I compile with GCC 4.5, libb is not loaded.
I have a small test case that consists of two files, a.c and b.c . The contents of the files:
//a.c
int a(){
return 0;
}
//b.c
int b(){
return 0;
}
//c.c
#include <stdio.h>
int a();
int b();
int main()
{
printf("%d\n", a()+b());
return 0;
}
//test.sh
$CC -o liba.so a.c -shared
$CC -o libb.so b.c -shared -L. -la -Wl,-rpath-link .
$CC c.c -L. -lb -Wl,-rpath-link .
LD_LIBRARY_PATH=. ./a.out
This is my output with different versions of GCC
$ CC=gcc-4.4 ./test.sh
1
$ CC=gcc-4.5 ./test.sh
/tmp/cceJhAqy.o: In function `main':
c.c:(.text+0xf): undefined reference to `a'
collect2: ld returned 1 exit status
./test.sh: line 4: ./a.out: No such file or directory
$ CC=gcc-4.6 ./test.sh
/tmp/ccoovR0x.o: In function `main':
c.c:(.text+0xf): undefined reference to `a'
collect2: ld returned 1 exit status
./test.sh: line 4: ./a.out: No such file or directory
$
Can anyone explain what is happening? Another extra bit of information is that ldd on libb.so does show liba.so on GCC 4.4 but not on GCC 4.5.
EDIT
I changed test.sh to the following:
$CC -shared -o liba.so a.c
$CC -L. -Wl,--no-as-needed -Wl,--copy-dt-needed-entries -la -shared -o libb.so b.c -Wl,-rpath-link .
$CC -L. c.c -lb -Wl,-rpath-link .
LD_LIBRARY_PATH=. ./a.out
This gave the following output with GCC 4.5:
/usr/bin/ld: /tmp/cc5IJ8Ks.o: undefined reference to symbol 'a'
/usr/bin/ld: note: 'a' is defined in DSO ./liba.so so try adding it to the linker command line
./liba.so: could not read symbols: Invalid operation
collect2: ld returned 1 exit status
./test.sh: line 4: ./a.out: No such file or directory
There seems to have been changes in how DT_NEEDED libraries are treated during linking by ld. Here's the relevant part of current man ld:
With --copy-dt-needed-entries dynamic libraries mentioned on the command
line will be recursively searched, following their DT_NEEDED tags to other libraries, in order to resolve symbols required by the output binary. With the
default setting however the searching of dynamic libraries that follow it will stop with the dynamic library itself. No DT_NEEDED links will be traversed
to resolve symbols.
(part of the --copy-dt-needed-entries section).
Some time between GCC 4.4 and GCC 4.5 (apparently, see some reference here - can't find anything really authoritative), the default was changed from the recursive search, to no recursive search (as you are seeing with the newer GCCs).
In any case, you can (and should) fix it by specifying liba in your final link step:
$CC c.c -L. -lb -la -Wl,-rpath-link .
You can check that this linker setting is indeed (at least part of) the issue by running with your newer compilers and this command line:
$CC c.c -L. -Wl,--copy-dt-needed-entries -lb -Wl,--no-copy-dt-needed-entries \
-Wl,-rpath-link .
I have a working setup, where all files are in the same directory (Desktop). The Terminal output is like so:
$ gcc -c mymath.c
$ ar r mymath.a mymath.o
ar: creating archive mymath.a
$ ranlib mymath.a
$ gcc test.c mymath.a -o test
$ ./test
Hello World!
3.14
1.77
10.20
The files:
mymath.c:
float mysqrt(float n) {
return 10.2;
}
test.c:
#include <math.h>
#include <stdio.h>
#include "mymath.h"
main() {
printf("Hello World!\n");
float x = sqrt(M_PI);
printf("%3.2f\n", M_PI);
printf("%3.2f\n", sqrt(M_PI));
printf("%3.2f\n", mysqrt(M_PI));
return 0;
}
Now, I move the archive mymath.a into a subdirectory /temp. I haven't been able to get the linking to work:
$ gcc test.c mymath.a -o test -l/Users/telliott_admin/Desktop/temp/mymath.a
i686-apple-darwin10-gcc-4.2.1: mymath.a: No such file or directory
$ gcc test.c -o test -I/Users/telliott_admin/Desktop/temp -lmymath
ld: library not found for -lmymath
collect2: ld returned 1 exit status
What am I missing? What resources would you recommend?
Update: Thanks for your help. All answers were basically correct. I blogged about it here.
$ gcc test.c /Users/telliott_admin/Desktop/temp/mymath.a -o test
edit: gcc only needs the full path to the library for static libraries. You use -L to give a path where gcc should search in conjunction with -l.
To include the math libraries, use -lm, not -lmath. Also, you need to use -L with the subdirectory to include the library when linking (-I just includes the header for compiling).
You can compile and link with:
gcc test.c -o test -I/Users/telliott_admin/Desktop/temp /Users/telliott_admin/Desktop/temp/mymath.a
or with
gcc test.c -o test -I/Users/telliott_admin/Desktop/temp -L/Users/telliott_admin/Desktop/temp -lmymath
where mymath.a is renamed libmymath.a.
See link text for comments (search for "bad programming") on the practices of using -l:
In order for ld to find a library with -l, it must be named according to the pattern libyourname.a. Then you use -lmymath
So, there is no way to get it to take /temp/mymath.a with -l.
If you named it libmymath.a, then -L/temp -lmymath would find it.