I am trying to compile a c program for windows and ubuntu to do that i am using mingw but it seems that it cant find the required libraries that gcc can find
when i execute this command
gcc decode_video.c -o dv -lavcodec -lavutil
Everything compiles normally but when i use this
x86_64-w64-mingw32-gcc decode_video.c -o dv.exe -lavcodec -lavutil
it says that header files arent found
after changing the build command to
x86_64-w64-mingw32-gcc decode_video.c -o dv.exe -I /usr/include/x86_64-linux-gnu -L /usr/lib/x86_64-linux-gnu -l avcodec -l avutil
it know gives me this error even though the libraries are linked
/tmp/ccgn1NTi.o:decode_video.c:(.text+0x138): undefined reference to `avcodec_send_packet'
/tmp/ccgn1NTi.o:decode_video.c:(.text+0x192): undefined reference to avcodec_receive_frame'
/tmp/ccgn1NTi.o:decode_video.c:(.text+0x33f): undefined reference toav_packet_alloc'
/tmp/ccgn1NTi.o:decode_video.c:(.text+0x37d): undefined reference to avcodec_find_decoder'
/tmp/ccgn1NTi.o:decode_video.c:(.text+0x3d0): undefined reference toav_parser_init'
/tmp/ccgn1NTi.o:decode_video.c:(.text+0x421): undefined reference to avcodec_alloc_context3'
/tmp/ccgn1NTi.o:decode_video.c:(.text+0x481): undefined reference toavcodec_open2'
/tmp/ccgn1NTi.o:decode_video.c:(.text+0x512): undefined reference to av_frame_alloc'
/tmp/ccgn1NTi.o:decode_video.c:(.text+0x5fc): undefined reference toav_parser_parse2'
/tmp/ccgn1NTi.o:decode_video.c:(.text+0x6f8): undefined reference to av_parser_close'
/tmp/ccgn1NTi.o:decode_video.c:(.text+0x707): undefined reference toavcodec_free_context'
/tmp/ccgn1NTi.o:decode_video.c:(.text+0x716): undefined reference to av_frame_free'
/tmp/ccgn1NTi.o:decode_video.c:(.text+0x722): undefined reference toav_packet_free'
collect2: error: ld returned 1 exit status
Finally, it turned that you tried to link against libraries for an incompatible architecture:
Why can't mingw find libraries that gcc can find?
Either compiler are using different default options for the linker.
Even with same -L <path> and same LD_LIBRARY_PATH etc., the linker will skip incompatible libraries. In your case, gcc is presumably hosted by
x86_64-linux-gnu, whereas x86_64-w64-mingw32-gcc is obviously hosted by x86_64-w64-mingw32. Both are incompatible.
Try adding -I <path> to the compilation where <path> contains libavcodec/avcodec.h. Add more -I if you need more paths. Use -isystem <path> if it's supposed to be system headers. Add -v -H to the compilation to see what include paths are in use. gcc prints:
#include "..." search starts here:
#include <...> search starts here:
Try adding -L <path> to the link stage where <path> contains the libraries like lib*.a / lib*.so to be linked against. Add -Wl,-v to see which options the compiler driver passes to the GNU linker ld.
Make sure the symbols are in the libraries, e.g. using tools like nm or x86_64-w64-mingw32-nm.
Make sure you are using libraries cross-compiled using the x86_64-w64-mingw32 toolchain.
Related
My system is an older NAS running 2.6.32. I have found that when using -static for any subsequent library, it will also try to statically link any other library that I might need.
When I add the -Wl,-Bdynamic flag first and then explicitly name those libraries using -lc, such as "-Wl,-Bdynamic -lc -lstdc++" then it works. So what happens is that libc and others fail to be statically linked.
The static libc on the system is called /opt/lib/libc_nonshared.a.
The contents of /opt/lib/libc.so is this:
OUTPUT_FORMAT(elf32-littlearm)
GROUP ( /lib/libc.so.6 /opt/lib/libc_nonshared.a )
The gcc version is 4.2.3. The current build command I am facing adds -dynamic at the end but this doesn't help much. When I add some static library directly using its .a name, and not using a -l flag, then there is no issue.
The problem seems to be that the dynamic library of libc came with the NAS, but the static version sits in /opt/lib.
I run:
gcc hamming.c -static -L. -L/opt/lib -l:matrix.a -o hamming
I get:
/opt/lib/gcc/arm-none-linux-gnueabi/4.2.3/../../../../arm-none-linux-gnueabi/bin/ld: cannot find -lc
collect2: ld returned 1 exit status
make: *** [hamming] Error 1
when I try to use static libc as is. Were I to perform a 'hack' to link libc_nonshared.a to libc.a, it suddenly does find it. But complains:
hamming.c:54: undefined reference to `malloc'
hamming.c:54: undefined reference to `memset'
And a zillion other errors of course. As mentioned above, /opt/libc.so contains the reference to both files (dynamic and static).
For libstdc++ only a .la file exists.
The -static linker flag does not take any argument. It is a boolean
flag that simply directs the linker to link no shared libraries, as
documented
-static
Do not link against shared libraries...
There is no need to explicitly direct the linker to link shared (dynamic)
libraries when it has a choice because that is the default bevaiour. If
you simply link, e.g.
gcc -o prog ... -lfoo ...
then the linker will link the first of libfoo.so (shared) or libfoo.a
(static) that it finds in any of the specified (-Ldir) or default
search directories, searched in commandline sequence. If it finds both
libfoo.so and libfoo.a in the same directory then it will choose
libfoo.so. Thus shared and static libraries may be freely intermixed
without any special options.
Specify -static only if you wish to link only static libraries.
If you wish to insist on linking a particular libfoo.a even when
libfoo.so is in the same directory and would be chosen by default,
use the explicit form of the -l option: -l:libfoo.a
Later
gcc hamming.c -static -L. -L/opt/lib -l:matrix.a -o hamming
This command is failing with:
ld: cannot find -lc
because the linker (ld) cannot find a static library libc.a in
any of the specified linker search directories (-L. -L/opt/lib) or
the default linker search directories. If you wish instead to link
/opt/lib/libc_nonshared.a then your command should be:
>gcc hamming.c -static -L. -L/opt/lib -l:matrix.a -lc_nonshared -o hamming
However, you have not explained why you want to link this program statically
(-static) in the first place, which is not the usual way and will require you to have installed
static versions of all libraries required for the linkage - both those
you explicitly link and the default libraries that gcc will add for C language
linkage (Standard C library, GCC runtime library).
Supposing you have a static library called (oddly) matrix.a (rather
than normally, libmatrix.a) that is located in /some/dir/, then the
normal way to compile and link your program would be:
gcc hamming.c -L/some/dir -l:matrix.a -o hamming
I suggest you start with that and deviate only as problems compel
you to.
The discovery of an /opt/lib/libc.so containing:
OUTPUT_FORMAT(elf32-littlearm)
GROUP ( /lib/libc.so.6 /opt/lib/libc_nonshared.a )
is misleading you. This is not your shared libc. A shared library
is a binary. This is a linker script, and it says that your shared libc
is in fact /lib/libc.so.6. The linker will almost certainly find and use it by default.
On building Glibc on my toolchain . The libraries make succesfully (and test ok) all FLAGS unset except for those specified for building default glibc. then i start building the programs both with and without FLAGS on seperate fresh build attempts and every time something in the iconv folder always breaks...
I'll diverge for a second to moan how its always iconv that breaks in GLibc for me and always has done for as long as i can remember... moving on though....
When gcc-4.8.0 is passed gcc -nostdlib -nostartfiles -o /glibc-build/iconv/iconvconfig -Wl,-dynamic-linker=/tools/lib/ld-linux-x86-64.so.2 -Wl,--hash-style=both -Wl,--warn-shared-textrel,--fatal-warnings /glibc-build/csu/Scrt1.o /glibc-build/csu/crti.o gcc --print-file-name=crtbeginS.o /glibc-build/iconv/iconvconfig.o /glibc-build/iconv/strtab.o /glibc-build/iconv/xmalloc.o /glibc-build/iconv/hash-string.o -Wl,-rpath-link=/glibc-build:/glibc-build/math:/glibc-build/elf:/glibc-build/dlfcn:/glibc-build/nss:/glibc-build/nis:/glibc-build/rt:/glibc-build/resolv:/glibc-build/crypt:/glibc-build/nptl /glibc-build/libc.so.6 /glibc-build/libc_nonshared.a -Wl,--as-needed /glibc-build/elf/ld.so -Wl,--no-as-needed -lgcc gcc --print-file-name=crtendS.o /glibc-build/csu/crtn.o
gcc -nostdlib -nostartfiles -o /glibc-build/iconv/iconv_prog -Wl,-dynamic-linker=/tools/lib/ld-linux-x86-64.so.2 -Wl,--hash-style=both -Wl,--warn-shared-textrel,--fatal-warnings /mnt/lfs/glibc-build/csu/Scrt1.o /glibc-build/csu/crti.o gcc --print-file-name=crtbeginS.o /glibc-build/iconv/iconv_prog.o /glibc-build/iconv/iconv_charmap.o /glibc-build/iconv/charmap.o /glibc-build/iconv/charmap-dir.o /glibc-build/iconv/linereader.o /glibc-build/iconv/dummy-repertoire.o /glibc-build/iconv/simple-hash.o /glibc-build/iconv/xstrdup.o /glibc-build/iconv/xmalloc.o -Wl,-rpath-link=/glibc-build:/glibc-build/math:/glibc-build/elf:/glibc-build/dlfcn:/glibc-build/nss:/glibc-build/nis:/glibc-build/rt:/glibc-build/resolv:/glibc-build/crypt:/glibc-build/nptl /glibc-build/libc.so.6 /glibc-build/libc_nonshared.a -Wl,--as-needed /glibc-build/elf/ld.so -Wl,--no-as-needed -lgcc gcc --print-file-name=crtendS.o /glibc-build/csu/crtn.o
i get 2 pages of referencing issues
/glibc-build/iconv/iconvconfig.o: In function more_help':
iconvconfig.c:(.text+0x12e): undefined reference to__tsan_func_entry'
iconvconfig.c:(.text+0x136): undefined reference to __tsan_write8'
iconvconfig.c:(.text+0x150): undefined reference to__tsan_func_exit'
iconvconfig.c:(.text+0x1cc): undefined reference to __tsan_read8'
/glibc-build/iconv/iconvconfig.o: In functionalias_compare':
iconvconfig.c:(.text+0x226): undefined reference to __tsan_func_entry'
iconvconfig.c:(.text+0x233): undefined reference to__tsan_read1'
iconvconfig.c:(.text+0x246): undefined reference to __tsan_read8'
iconvconfig.c:(.text+0x25d): undefined reference to__tsan_read1'
iconvconfig.c:(.text+0x26e): undefined reference to __tsan_read8'
iconvconfig.c:(.text+0x282): undefined reference to__tsan_func_exit'
iconvconfig.c:(.text+0x2b4): undefined reference to __asan_report_load8'
iconvconfig.c:(.text+0x2b9): undefined reference to__asan_report_load8'
/glibc-build/iconv/iconvconfig.o: In function module_compare':
iconvconfig.c:(.text+0x2fb): undefined reference to__tsan_func_entry'
iconvconfig.c:(.text+0x308): undefined reference to __tsan_read1'
iconvconfig.c:(.text+0x326): undefined reference to__tsan_read8'
iconvconfig.c:(.text+0x337): undefined reference to __tsan_read1'
iconvconfig.c:(.text+0x34a): undefined reference to__tsan_read8'
iconvconfig.c:(.text+0x36f): undefined reference to __tsan_func_exit'
iconvconfig.c:(.text+0x3a6): undefined reference to__asan_report_load8'
iconvconfig.c:(.text+0x3ab): undefined reference to __asan_report_load8'
/glibc-build/iconv/iconvconfig.o: In functionname_compare':
after 2 weeks of trying to get it to compile every which way possible im getting a bit fed up. Any ideas please?
Emma
A bit late, but hopefully useful.
The symbols with tsan and asan in their name are related to the address sanitizer project that provides LLVM clang and gcc with tools to detect and report a whole range of problems related to illegal memory access.
To use them you have to install tools and libraries, use the correct versions of the compilers and the correct combinations of flags during compile and linking depending on your version.
In my experience the documentation is only so useful, and the topic is pretty advanced. In my project over which I have full control, I ended up disabling all but the one commandline parameter -fsanitize=address together with the recommended -fno-omit-frame-pointer for both compile and link (gcc 4.8 on x64 ubuntu 14.04LTS).
Since you are attempting to build an existing project, you are at the mercy of their settings. I would look at docs for that project and try to determine the recommended versions of compiler and sanitizer tools from there, or maybe some configuration options to disable it if you don't care.
I am trying to build a tool called sscep (http://www.klake.org/~jt/sscep/) for Windows. It does not run natively and I have a "patch" that changes sscep to make it compile on Windows.
After applying the patch, it does compile perfectly but the linker screws. I am using gcc in minGW/msys
The original messsage was that it couldn't find the crypto lib so I added the library with "-L../openssl-mingw/lib" which then didn't create any more errors. I also have the command line switch -lcrypto in my command: gcc -L../openssl-mingw/lib -lcrypto sscep.o init.o net.o sceputils.o pkcs7.o ias.o fileutils.o -o sscep.In this directory is a libcrypto.a. OpenSSL itself was compiled with the exact same compiler just running ./config && make && make test && make install. Also the sources were extracted using the minGW tar and not 7-zip.
After following all documentation this is my (truncated) output:
sscep.o:sscep.c:(.text+0x83): undefined reference to `WSAStartup#8'
sscep.o:sscep.c:(.text+0xa5): undefined reference to `WSACleanup#0'
sscep.o:sscep.c:(.text+0x3d5): undefined reference to `BIO_new_mem_buf'
sscep.o:sscep.c:(.text+0x3e0): undefined reference to `ASN1_INTEGER_new'
sscep.o:sscep.c:(.text+0x414): undefined reference to `a2i_ASN1_INTEGER'
sscep.o:sscep.c:(.text+0x432): undefined reference to `ASN1_INTEGER_to_BN'
sscep.o:sscep.c:(.text+0x448): undefined reference to `BN_bn2dec'
sscep.o:sscep.c:(.text+0xb7e): undefined reference to `EVP_des_cbc'
sscep.o:sscep.c:(.text+0xbaf): undefined reference to `EVP_bf_cbc'
sscep.o:sscep.c:(.text+0xbda): undefined reference to `EVP_des_cbc'
sscep.o:sscep.c:(.text+0xc02): undefined reference to `EVP_des_ede3_cbc'
sscep.o:sscep.c:(.text+0xc48): undefined reference to `EVP_md5'
sscep.o:sscep.c:(.text+0xc79): undefined reference to `EVP_md5'
sscep.o:sscep.c:(.text+0xca1): undefined reference to `EVP_sha1'
This goes on for every file in there and supposedly every function called.
Searching here and google resulted in a missing library but omitting the -L directive from above I get another error about not finding libcrypto. So I assume that the library is actually found but somewhat with wrong addresses or something?
Here my compiler/linker knowledge actually ends.
If it is possible that the patch is responsible for that (which I do not believe since these are all openssl functions and the compiling works) then I can provide you with it.
Edit: Is there any information that I should provide so someone can help me? The version of openssl is 1.0.1 if this makes any difference.
On this topic: If it does make a difference, could this error occur because of a wrong version. As far as I understand linker theory, this error should not originate from a wrong version unless all of the below functions were replaced by differently named ones (but then the compiler would have complained, I guess?).
Another addition: Since I am on a 64 bit Windows 7, I tried to compile it with -m32 flag but that did not help. I assume since mingw is already 32 bit only, I can't even build x64. Another question is whether it is a problem that I am running in a virtualized environment on an AMD Opteron while openssl is built with the command "-march=i486"?
With some help I could finally figure this out! It was a problem of the order AND a problem of missing libraries. The combination killed me.
The libraries had to be -lcrypto -lws2_32 -lgdi32 not just -lcrypto. Furthermore, I had to append the libraries after the object files, so: $(CC) $(CFLAGS) $(OBJS) -lcrypto -lws2_32 -lgdi32 -o $(PROG) was the right make line.
Finally with this, it compiles fine. I didn't even need any architecture flags and such.
and sorry for my not really good english. I'll try my best :)
I am trying to compile a addin for my Casio graphic calculator in C. This works without problems when using the official SDK. Because it is only available for Windows, I want to use gcc.
So I got sh-rtems-gcc and it's binutils from macports and tried to compile my program according to this instructions. I copy-pasted the described addin.ld and crt0.s and placed my main.c and libfxsys.a (from the same guys as the instructions mentioned above) in the same directory. The sub-dir include contains fxsys' headers. I verified the presence of all the functions of the library in the .a file with nm.
When using this command for compilation:
sh-rtems-gcc-4.2.3 -m3 -mb -nostdlib -I./include -c crt0.s main.c
Everything works fine. But then im trying to link:
sh-rtems-gcc-4.2.3 -m3 -mb -nostdlib -L. -o myaddin.elf -Taddin.ld crt0.o main.o -lfxsys
and get the following error:
main.o: In function `__main':
main.c:(.text+0x248): undefined reference to `_Bdisp_AllClr_VRAM'
...
... (--- cut 16 other errors in the same format ---)
...
main.c:(.text+0x360): undefined reference to `_Sleep'
./libfxsys.a(locate.o): In function `_locate':
locate.c:(.text+0x28): undefined reference to `_locate_OS'
collect2: ld gab 1 als Ende-Status zurück
All the missing symbols are in the libfxsys.a. I have verified this with nm.
I have already played with the positions of the library in the command, as this is often mentioned as a source of failure in other posts found in google, but without success. I also tried adding and removing the -lgcc option that is used in the above mentioned instructions, without success.
My Host-Machine is a Intel Mac, OS X 10.6
Because I have no idea how to solve this problem, and get to compile my program, I have to ask: What am I doing wrong? How can I compile my program without using the SDK?
Thanks in advance,
xythobuz
Edit:
I have also tried linking with:
sh-rtems-ld -EB -L. -o myaddin.elf -Taddin.ld crt0.o --start-group main.o libfxsys.a --end-group
But it produces the same output as above.
I can't say the exact problem, but would investigate like this:
Find the library that contains the missing symbols. Use nm to see symbol names
Once you know which library contains the symbols make sure you're linking to it, and in the correct order. Try using recursive symbol resolution options -( -) with your linker.
On my system, expat is located at
/usr/include/expat.h
/usr/include/expat_external.h
/usr/lib/libexpat.1.5.0.dylib
/usr/lib/libexpat.1.dylib
/usr/lib/libexpat.dylib
/usr/lib/libexpat.la
So I export the required variables for boost to build graphml
export EXPAT_INCLUDE=/usr/include
export EXPAT_LIBPATH=/usr/lib
then I run (where $DIR and $BOOST generate the paths I want the includes and libs to go)
./configure --includedir=$DIR/$BOOST --libdir=$DIR/$BOOST/lib \
--with-libraries=test,graph
I get this error:
ld: library not found for -lexpat collect2: ld returned 1 exit status
which boost says is caused by the line:
g++ -dynamiclib -install_name "libboost_graph-mt-1_35.dylib" -L"/usr/lib"
-o "bin.v2/libs/graph/build/darwin/release/macosx-version-10.4/threading-multi/libboost_graph-mt-1_35.dylib"
"bin.v2/libs/graph/build/darwin/release/macosx-version-10.4/threading-multi/read_graphviz_spirit.o"
"bin.v2/libs/graph/build/darwin/release/macosx-version-10.4/threading-multi/graphml.o"
-lexpat -isysroot /Developer/SDKs/MacOSX10.4u.sdk -mmacosx-version-min=10.4 -Wl,-dead_strip -no_dead_strip_inits_and_terms
I don't get how it's not finding the expat library with -L"/usr/lib" and -lexpat as arguments? My understanding is that /usr/lib/libexpat.dylib is exactly referenced as -L"/usr/lib" and -lexpat.
The Jamfile for building graphml is here. If EXPAT_INCLUDE and EXPAT_LIBPATH aren't set then it warns you (lines 39-41 of jamfile)
warning: Graph library does not contain optional GraphML reader.
note: to enable GraphML support, set EXPAT_INCLUDE and
note: directories containing the Expat headers and libraries, respectively.
Another update:
I don't see an .so or a .a file in your list of where EXPAT is... doesn't that seem a bit strange? Normally it will create an alias for the library name
for example /usr/lib/libblah.so -> /usr/lib/libblaah.so.1.2
Is dynalib some Macintoshism (I don't use Macs much)
is .la the static version extension on this platform?
Update:
The quotes around the path seem troublesome...
-L"/usr/lib"
Try changing this to -L/usr/lib and -L /usr/lib
Older stuff:
The directive for the linker to include paths during the link step is -L. You need to look for some linker flags to update to include -L path_to_expat. I don't think the linker pays any attention to LD_LIBRARY_PATH. I am not sure what documentation you have read to set EXPAT_INCLUDE or EXPAT_LIBPATH.