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.
Related
Im trying to link with a game library that has already been compiled using mingw, called Raylib. However; whenever I use MSYS's gcc 10.2 it gives me the following undefined reference error:
gcc main.c -Iraylib-3.7.0_win64_mingw-w64/include -Lraylib-3.7.0_win64_mingw-w64/lib -lraylib -lopengl32 -lgdi32 -lwinmm
/usr/lib/gcc/x86_64-pc-msys/10.2.0/../../../../x86_64-pc-msys/bin/ld: raylib-3.7.0_win64_mingw-w64/lib/libraylib.a(core.o):core.c:(.text+0x1f6e): undefined reference to '_assert'
It seems that I maybe missing a library? This is just one of many similar errors. The majority of these undefined references are for assert like the one listed above. Some deal with GLFW and other libraries. Has anyone experienced something like this on MSYS?
Looks like I needed to be directly in MSYS2 mingw64 environment (cmd prompt). I was using the regular MSYS2 MSYS environment.
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.
This is my linker command:
arm-none-eabi-ld boot_and_link/startup.o drivers/gpio.o ../programs/dmips/dhry_1.o ../programs/dmips/dhry_2.o -nostartfiles -T boot_and_link/linker.ld -L/usr/lib/gcc/arm-none-eabi/4.8/armv6-m -lgcc -L/usr/lib/arm-none-eabi/newlib/armv6-m/ -lc -L/usr/lib/arm-none-eabi/newlib/armv6-m/ -lnosys -o ../programs/dmips/dmips.elf
I'm using, my own startup code and my own linker script since I'm doing a bare metal compilation in an attempt to run Dhrystone benchmark on an Cortex M0 processor.
These are the errors I get:
/usr/lib/arm-none-eabi/newlib/armv6-m//libc.a(lib_a-fvwrite.o): In function `__sfvwrite_r':
/home/tin/projects/debian/arm-toolchain/collab-maint/newlib/build/arm-none-eabi/armv6-m/newlib/libc/stdio/../../../../../../newlib/libc/stdio/fvwrite.c:196: undefined reference to `__aeabi_idiv'
/usr/lib/arm-none-eabi/newlib/armv6-m//libnosys.a(sbrk.o): In function `_sbrk':
/home/tin/projects/debian/arm-toolchain/collab-maint/newlib/build/arm-none-eabi/armv6-m/libgloss/libnosys/../../../../../libgloss/libnosys/sbrk.c:14: undefined reference to `end'
The end symbol, as I understand it, should be the end of the heap right? I can get rid of it by setting it in the linker script.
However the other one is wierd. That symbol is declared in libgcc.a which is included.
In my opinion the problem is a simple path conflict: whatever fvwrite.o is, it wants to use that symbol and the linker is not looking for it in libgcc.a which exists and is added as parameter library. Keep in mind this is just a thought. I don't really know what is going on.
Any ideas?
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.
I am trying to use the functions from boost::filesystem to change my current working directory (and create it if necessary). I am getting linking errors:
SBDir.cpp:(.text+0x23): undefined reference to `boost::system::generic_category()'
SBDir.cpp:(.text+0x2f): undefined reference to `boost::system::generic_category()'
SBDir.cpp:(.text+0x3b): undefined reference to `boost::system::system_category()'
But I am linking against the boost libraries??!? I use the following:
-lboost_system -lboost_system-mt -lboost_filesystem -lboost_filesystem-mt
And I know it can find them because with -Wl, -t I get:
-lboost_system (/usr/lib/gcc/x86_64-linux-gnu/4.4.3/../../../../lib/libboost_system.so)
-lboost_system-mt (/usr/lib/gcc/x86_64-linux-gnu/4.4.3/../../../../lib/libboost_system-mt.so)
-lboost_filesystem (/usr/lib/gcc/x86_64-linux-gnu/4.4.3/../../../../lib/libboost_filesystem.so)
-lboost_filesystem-mt (/usr/lib/gcc/x86_64-linux-gnu/4.4.3/../../../../lib/libboost_filesystem-mt.so)
FWIW: I'm using gcc Ubuntu 4.4.3-4ubuntu54.4.3.
I had this same error message with boost 1.46 (standard with Ubuntu 11.10) and I had to add -lboost_system which I didn't need in 11.04 and boost 1.42. It doesn't answer your question but possibly of interest to others brought here by googling the error message.
So I couldn't figure out what went wrong -- so I tried un-installing the Ubuntu boost package and building it from scratch. I upgraded to 1.45.0 & now everything links. Not sure whether this was a version specific problem or not, but if I learn more later I'll come back and update.