I'm trying to link FFmpeg libraries to a C program on Windows, but I can't successfully link the libraries. I downloaded the Dev archive from Zeranoe and put it into my project folder. (EDIT: The 64-bits version). The compilation works well but when I'm trying to link libraries, I get some undefined reference errors. Here is the command I'm trying:
gcc -o .\metadata.exe .\metadata.o -L .\ffmpeg-20170628-c1d1274-win64-dev\lib\ -lavutil -lavformat -lavdevice -lavfilter -lavcodec -lswresample -lswscale -lm
It then outputs me:
.\metadata.o:metadata.c:(.text+0x44): undefined reference to 'av_register_all'
.\metadata.o:metadata.c:(.text+0x6c): undefined reference to 'avformat_open_input'
.\metadata.o:metadata.c:(.text+0xc8): undefined reference to 'av_dict_get'
.\metadata.o:metadata.c:(.text+0xdf): undefined reference to 'avformat_close_input'
Paths are good because if I change the -libs parameters or the -L parameter I get files not found errors. Finally, I took those libraries from the Makefile in the examples' folder.
What is the source of the error? Thanks in advance, have a nice day!
EDIT: Okay so I found what was the problem. As I'm using MinGW, it includes a 32-bits compiler. So as I downloaded the 64-bits, something was off. I tried downloading the 32-bits builds and it built and linked successfully with only -lavformat and -lavutil parameters. And to run the program I needed the DLL which can be found in the Shared build (and 32-bits of course) on Zeranoe's website. Thanks!
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 have compiled and installed the 2.2.7.2 version of libxml. While compiling, I have this error: Makefile:755: recipe for target 'install-data-local' failed. But the lib files are correctly generated (libxml2.a and libxml2.so).
I'd like to use libxml2 in a C project so I edited my makefiles in order to integrate lib files (libxml2.a and libxml2.so).
The problem is that when I compile my project I get the followings errors:
/libxml2.a(xmlIO.o): In function xmlGzfileRead': undefined reference togzdopen'
/libxml2.a(xmlIO.o): In function xmlGzfileRead': undefined reference togzclose'
/libxml2.a(xmlIO.o): In function xmlGzfileRead': undefined reference togzread'
...etc
It seems that I have to install the zlib library in order to resolve this linker errors. I installed the zlib library and edited the LD_LIBRARY_PATH in order to add the path where are the zlib libraries.
I recompiled my project, but I still always having the same linker errors.
Would you please help me to resolve those linker errors.
Regards.
See the libxml2 FAQ:
Troubles compiling or linking programs using libxml2
Usually the problem comes from the fact that the compiler doesn't get the right compilation or linking flags. There is a small shell script xml2-config which is installed as part of libxml2 usual install process which provides those flags. Use
xml2-config --cflags
to get the compilation flags and
xml2-config --libs
to get the linker flags. Usually this is done directly from the Makefile as:
CFLAGS=`xml2-config --cflags`
LIBS=`xml2-config --libs`
On my current system, the output from xml2-config --libs is
-lxml2 -lz -lpthread -licucore -lm
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'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 currently trying to compile Clang/LLVM for a bare metal aarch64 target. Compiling Clang was straightforward - in fact I have compiled to target multiple architectures including arm and aarch64. For the backend I'm using binutils. Since binutils can only target one architecture I've built both aarch64 and arm versions of this. Again building seemed to be straightforward. I built binutils for aarch64 using:
mkdir build
cd build
../configure --target=aarch64-none-elf
make
from an unpacked source package of binutils 2.24.
The problem I'm having is that I can't get my custom build of ld to handle archive files properly. It seems to find and open archive files without a problem but fails to search it for undefined symbols when compiling the final binary. Here's some more concrete details via an example:
Create a simple main.s file by compiling:
int foo();
int main() { return foo(); }
with Clang and using --target=aarch64 -S, i.e. to emit an architecture specific assembly file.
Do the same to create foo.s by compiling:
int foo() { return 0; }
Assemble both .s files to .o files using custom gas build from binutils.
Create an archive libfoo.a by running custom ar and ranlib builds from binutils using ar cr foo.a foo.s and ranlib libfoo.a.
Try to link the two files together using ld -L. -lfoo -o main.elf main.o.
The output shows an undefined reference to foo.
bar.cpp:(.text+0x14): undefined reference to `foo()'
I can run readelf on foo.a and it seems perfectly well formed. In particular I can see the public symbol for foo. If I run ld with --verbose then I see
attempt to open ./libfoo.a succeeded
but no indication that it's found any symbols.
If I link directly with the object files, i.e. using ld -o main.elf foo.o main.o then I get a well formed elf file. Furthermore, if I extract foo.o back out of libfoo.a then I can also link succesfully with the extracted foo.o.
Does anyone have any ideas why this might be happening? I'm pretty sure my clang build is okay as the emitted assembly files effectively decouple the problem from clang. I'd guess also that the assembled .o files are fine. So this only leaves ar/ranlib or ld as the culprit.
To try to eliminate ar/ranlib as the culprits I rebuilt binutils for arm (same steps but using --target=arm-none-eabi). If I integrate the built ar/ranlib binaries into a known good arm-eabi-none GCC toolchain then they seem to work correctly. My suspicions thus point to ld at the moment. Note that I get the same problem with the main/foo example as above if I use my Clang build with the arm build of binutils.
I also tried integrating the arm version of ld into the existing known good GCC toolchain, but got:
this linker was not configured to use sysroots
Need to figure that out. That's still a bit cryptic for me right now. It prevents me from sanity checking the arm ld build.
It might well be that I'm doing something obviously wrong, but right now I don't see it.
Notes:
I had to hack the make script for binutils to add a couple of -Wno-xxx flags. I need to do this the "correct" way, but I don't think this hack should affect the output.
I'm building/hosting all tools on OSX 10.9.4 64-bit.
UPDATE:
The error about sysroots is simple. The pre-existing toolchain was configured with flags:
--with-prefix $SOME_INSTALL_DIR
--with-sysroot $SOME_INSTALL_DIR/arm-none-eabi
If I rebuild with these then I can slot in my ld version without a problem and it works. I got excited thinking that this might have been my mistake. Previously I wasn't running make install as I didn't really care about installing at this stage. I thought perhaps my new build of ld was referencing OSX system libs/exes somehow (although I'm not sure exactly what it could reference, other than perhaps ar, i.e. if it runs ar to handle archives). However I still have the same problem with both the arm and arrach64 versions of binutils even when configured like this.
Looks like I was dramatically overthinking the problem and also missing something I'd never quite realised about ld. The issue was with the line:
ld -L. -lfoo -o main.elf main.o
I hadn't realise that ld is sensitive to object file/library ordering. The undefined reference to foo() was in main.o. I specified the library libfoo.a as input before main.o is parsed. This means that the linker doesn't bother searching libfoo.a for the symbol as it's already processed this library. main.o must be specified before, e.g.
ld -L. main.o -lfoo -o main.elf
Even wrapping -lfoo with --start-group ... --end-group doesn't fix this.
I'm still feeling somewhat surprised by this. And I've yet to convince myself it's a good feature of ld. Seems like the only use case I can think of right now is to sneakily allow duplicate symbols.
Time for a cup of tea!