I'm trying to build a project for ARM uClibc environment, but I've some functions missing. Can not find which library shall I include to resolve dependancies. nm do not help me to search, since it says on most of libs coming with toolchain:
nm: ./host/usr/arm-unknown-linux-uclibcgnueabi/sysroot/lib/libuClibc-0.9.32.1.so: no symbols
Here is the output from GCC:
./host/usr/bin/arm-unknown-linux-uclibcgnueabi-gcc
-Wl,-rpath,./host/usr/lib/
-Wl,-rpath,./host/usr/../lib/
-Wl,-rpath,./host/usr/arm-unknown-linux-uclibcgnueabi/sysroot/lib/
-Llibzway -o test_so main.o -lzway
-L./host/usr/lib/
-L./host/usr/../lib/
-L./host/usr/arm-unknown-linux-uclibcgnueabi/sysroot/lib/ -lpthread
-lxml2 -lz -lm
./host/usr/lib/libxml2.so: warning: gethostbyname is obsolescent, use getnameinfo() instead.
./host/usr/lib/libxml2.so: undefined reference to `fcntl64'
./host/usr/lib/libxml2.so: undefined reference to `fopen64'
./host/usr/../lib/libz.so: undefined reference to `lseek64'
./host/usr/lib/libxml2.so: undefined reference to `stat64'
./host/usr/lib/libiconv.so.2: undefined reference to `mbrtowc'
./host/usr/lib/libiconv.so.2: undefined reference to `_stdlib_mb_cur_max'
./host/usr/lib/libiconv.so.2: undefined reference to `wcrtomb'
./host/usr/lib/libxml2.so: undefined reference to `open64'
collect2: ld returned 1 exit status
make: *** [test_so] Error 1
UPD:
I've copied uClibc from the target host and explicitely defined asked to link with it:
./host/usr/bin/arm-unknown-linux-uclibcgnueabi-gcc
-Wl,-rpath,./host/usr/lib/
-Wl,-rpath,./host/usr/../lib/
-Wl,-rpath,./host/usr/arm-unknown-linux-uclibcgnueabi/sysroot/lib/
-Llibzway -o test_so main.o -lzway
-L./host/usr/lib/
-L./host/usr/../lib/
-L./host/usr/arm-unknown-linux-uclibcgnueabi/sysroot/lib/
-luClibc-0.9.31
-lpthread -lxml2 -lz -lm
./host/usr/bin/../lib/gcc/arm-unknown-linux-uclibcgnueabi/4.5.3/../../../../arm-unknown-linux-uclibcgnueabi/bin/ld:
errno: TLS reference in ./host/usr/bin/../arm-unknown-linux-uclibcgnueabi/sysroot/lib/libpthread.so.0 mismatches non-TLS definition in ./host/usr/lib/libuClibc-0.9.31.so section .bss
./host/usr/bin/../arm-unknown-linux-uclibcgnueabi/sysroot/lib/libpthread.so.0: could not read symbols: Bad value
collect2: ld returned 1 exit status
make: *** [test_so] Error 1
This is much bayond my knowledge of cross-compilation. Any idea?
It sounds like you have several issues going on:
You seem to be trying to use the host's copy of libxml2.so. This is not going to work. You need one built for your target system and its libc.
Your uClibc was compiled without large file support. Go back and fix the build options or uClibc. It's not strictly necessary (a correctly built libxml2.so linked against uClibc will work without doing this), but using the pre-large-file interfaces is really backwards and will unnecessarily limit your programs.
Related
I can’t figure out why I’m getting these compilation errors:
gcc -o Compil obj/MillerRabin.o obj/main.o -L. -L/usr/lib/ -Wl,-rpath=/home/---------/Documents/AC20_Cyrpto -lgmp -lCommon -ltest -lprimeGen
./libtest.so: undefined reference to `__gmpz_set_str'
./libtest.so: undefined reference to `__gmpz_set_ui'
./libtest.so: undefined reference to `__gmpz_add_ui'
./libtest.so: undefined reference to `__gmpz_clear'
./libtest.so: undefined reference to `__gmpz_init'
./libtest.so: undefined reference to `mpzPrint'
collect2: error: ld returned 1 exit status
Makefile:61: recipe for target 'Compil' failed
make: *** [Compil] Error 1
These errors are coming from libs/test/test.c, I’m using a make file that a friend of mine made, and I haven’t really looked into how they work yet.
So what’s weird is that in my libs folder I have another .c file that’s using gmp (libs/Common/common.h and mpzfunctions.c), and that one doesn’t give me any errors. If I move my test function to the main the compilation works.
If anyone knows how to fix this, it would be great! Thanks.
Symbols from libraries are applied in order. So when you write:
-lgmp -ltest
It means that symbols used in libgmp will be looked up in libtest but not vice versa.
Apparently, your libtest requires functions from libgmp, so you need to apply them in the opposite order.
As a rule of thumb, external libraries should always go last because they do not generally require symbols from your libraries.
So without knowing too much, I 'd guess that the order should be:
-lCommon -lprimeGen -ltest -lgmp
It looks to me like you will want to remove -lgmp from LINK_FLAGS and add it somehow to the end of the link command.
When trying to build some test cases (just programs written in Ada), I get the following error:
gcc -c -shared decimaltests.adb
gnatbind -x decimaltests.ali
gnatlink decimaltests.ali -lGenerics -lNumerics -lTesting
/usr/bin/ld: decimaltests: hidden symbol `_Unwind_Resume' in
/usr/lib/gcc/x86_64-pc-linux-gnu/7.2.1/libgcc_eh.a(unwind-dw2.o) is referenced by DSO
/usr/bin/ld: final link failed: Bad value
collect2: error: ld returned 1 exit status
gnatlink: error when calling /usr/bin/gcc
gnatmake: *** link failed.
I'm building them with gnatmake -shared *.ad{b,s} -largs -lGenerics -lNumerics -lTesting Clearly this isn't a problem with building the sources, but just to further confirm that, I copied the sources into this directory and built using gnatmake -shared *.ad{b,s} which built the tests just fine.
The dependent libraries are built and installed into a path gnat searches through. It doesn't seem to be an issue of not finding those. Not sure what's going on here.
All the libraries are built with gnatmake -O2 -fPIC -shared *.ad{b,s} as well as any relevant library dependencies. All libraries that depend on these can still be built. It's only even programs that depend on the libraries that throw this error, and always the same error.
Update: Building the libraries using gprbuild and then installing them with gprinstall seems to work similarly, except now the error is as follows:
decimaltests.o: In function `_ada_decimaltests':
decimaltests.adb:(.text+0x43): undefined reference to `testing__start'
decimaltests.adb:(.text+0x4a): undefined reference to
`generics__testing__default_tolerance'
decimaltests.adb:(.text+0x9e): undefined reference to
`generics__testing__default_tolerance'
decimaltests.adb:(.text+0x108): undefined reference to
`generics__testing__default_tolerance'
decimaltests.adb:(.text+0x172): undefined reference to
`generics__testing__default_tolerance'
decimaltests.adb:(.text+0x1dc): undefined reference to
`generics__testing__default_tolerance'
decimaltests.o:decimaltests.adb:(.text+0x23f): more undefined references to
`generics__testing__default_tolerance' follow
decimaltests.o: In function `_ada_decimaltests':
decimaltests.adb:(.text+0x14f5): undefined reference to `testing__stop'
/usr/lib/numerics//libNumerics.so: undefined reference to
`generics__testing__not_started#SYMS'
/usr/lib/numerics//libNumerics.so: undefined reference to
`generics__testing__pass#SYMS'
/usr/lib/numerics//libNumerics.so: undefined reference to
`generics__testing__fail#SYMS'
collect2: error: ld returned 1 exit status
gprbuild: link of decimaltests.adb failed
So I looked through the symbols table for both build methods and noticed, in both cases, the symbol most definitely exists, but the reference to it seems to be the wrong location. I'll try building on different platforms/compilers and update again if anything relevant comes up.
Both processes correctly build the libraries and test programs, and the test programs run properly, on different platforms. To further confirm that this is a bug, I've installed a different GCC toolchain and repeated the builds under the original platform, and this problem did not arise. I'll be filing a bug report.
I'm trying to install AODV protocol on Raspberry pi. After completing git clone from "https://github.com/erimatnor/aodv-uu" when I tried to do "make" and I am getting below error. Expecting your suggestion. Thank you!
make
gcc -Wall -O3 -g -DDEBUG -DCONFIG_GATEWAY -DDEBUG -o aodvd main.o list.o debug.o timer_queue.o aodv_socket.o aodv_hello.o aodv_neighbor.o aodv_timeout.o routing_table.o seek_list.o aodv_rreq.o aodv_rrep.o aodv_rerr.o nl.o locality.o
aodv_neighbor.o: In function neighbor_add':
/home/pi/aodv-uu/aodv_neighbor.c:68: undefined reference tohello_update_timeout'
aodv_timeout.o: In function route_discovery_timeout':
/home/pi/aodv-uu/aodv_timeout.c:98: undefined reference tort_table_update_timeout'
aodv_rreq.o: In function rreq_route_discovery':
/home/pi/aodv-uu/aodv_rreq.c:460: undefined reference tort_table_update_timeout'
aodv_rreq.o: In function rreq_local_repair':
/home/pi/aodv-uu/aodv_rreq.c:521: undefined reference tort_table_update_timeout'
aodv_rrep.o: In function rrep_forward':
/home/pi/aodv-uu/aodv_rrep.c:231: undefined reference tort_table_update_timeout'
nl.o: In function nl_kaodv_callback':
/home/pi/aodv-uu/nl.c:282: undefined reference tort_table_update_timeout'
collect2: error: ld returned 1 exit status
Makefile:112: recipe for target 'aodvd' failed
make: *** [aodvd] Error 1
The code available from sourceforge is the same code that is on github. If you download the archive, you'll see that the latest modification date of any file there is 2010. Given the age of this code, I wouldn't be surprised to find that things simply don't work anymore.
However, here's a quick workaround for your problem. The root cause appears to be that the problem functions, like rt_table_update_timeout, are declared as inline, but that information seems to get lost somewhere in the build process such that other object files are trying to reference these as non-inline functions.
You can avoid this by opening defs.h, looking for this line:
#define NS_INLINE inline
And replace it with:
#define NS_INLINE
This will allow aodvd to compile correctly (make aodvd). On my system, the kernel module will subsequently fail to compile:
cc1: fatal error: /lib/modules/4.13.15-100.fc25.x86_64/build/include/linux/modversions.h: No such file or directory
As far as I can tell, the modversions.h file is no longer produced by modern Linux kernels.
When i am trying to compile a C code which uses openssl 'crypto' library functions with comand line -lcrypto with gcc 4.4.3 it gives an error
`#ubu:$ gcc -ggdb aes_m.c -Werror -Wall -I /usr/local/ssl/include/ -lcrypto -o aes
/usr/bin/ld: cannot find -lcrypto
collect2: ld returned 1 exit status`
what can be the reason for this??
I have already gone through this discussion ld cannot find an existing library but that does not help.
locate command results in
$ locate libcrypto
/home/abhi/Downloads/openssl-1.0.1b/libcrypto.a
/home/abhi/Downloads/openssl-1.0.1b/libcrypto.pc
/lib/libcrypto.so.0.9.8
/lib/i486/libcrypto.so.0.9.8
/lib/i586/libcrypto.so.0.9.8
/lib/i686/cmov/libcrypto.so.0.9.8
/usr/lib/libcrypto.so.0.9.8
/usr/lib/vmware-tools/lib32/libcrypto.so.0.9.8
/usr/lib/vmware-tools/lib32/libcrypto.so.0.9.8/libcrypto.so.0.9.8
/usr/lib/vmware-tools/lib64/libcrypto.so.0.9.8
/usr/lib/vmware-tools/lib64/libcrypto.so.0.9.8/libcrypto.so.0.9.8
/usr/local/ssl/lib/libcrypto.a
/usr/local/ssl/lib/pkgconfig/libcrypto.pc
Can someone please help on this or point out any mistake i am doing
# Daniel Roethlisberger tried using the -L flag but that resulted in these errors
gcc -ggdb aes_m.c -Werror -Wall -I /usr/local/ssl/include/ -L /usr/local/ssl/lib -lcrypto -o aes
/usr/local/ssl/lib/libcrypto.a(dso_dlfcn.o): In function `dlfcn_globallookup':
dso_dlfcn.c:(.text+0x2d): undefined reference to `dlopen'
dso_dlfcn.c:(.text+0x43): undefined reference to `dlsym'
dso_dlfcn.c:(.text+0x4d): undefined reference to `dlclose'
/usr/local/ssl/lib/libcrypto.a(dso_dlfcn.o): In function `dlfcn_pathbyaddr':
dso_dlfcn.c:(.text+0x8f): undefined reference to `dladdr'
dso_dlfcn.c:(.text+0xe9): undefined reference to `dlerror'
/usr/local/ssl/lib/libcrypto.a(dso_dlfcn.o): In function `dlfcn_bind_func':
dso_dlfcn.c:(.text+0x4b1): undefined reference to `dlsym'
dso_dlfcn.c:(.text+0x590): undefined reference to `dlerror'
/usr/local/ssl/lib/libcrypto.a(dso_dlfcn.o): In function `dlfcn_bind_var':
dso_dlfcn.c:(.text+0x611): undefined reference to `dlsym'
dso_dlfcn.c:(.text+0x6f0): undefined reference to `dlerror'
/usr/local/ssl/lib/libcrypto.a(dso_dlfcn.o): In function `dlfcn_unload':
dso_dlfcn.c:(.text+0x755): undefined reference to `dlclose'
/usr/local/ssl/lib/libcrypto.a(dso_dlfcn.o): In function `dlfcn_load':
dso_dlfcn.c:(.text+0x837): undefined reference to `dlopen'
dso_dlfcn.c:(.text+0x8ae): undefined reference to `dlclose'
dso_dlfcn.c:(.text+0x8f5): undefined reference to `dlerror'
collect2: ld returned 1 exit status
Many thanks
Add -L /usr/local/ssl/lib/ into the GCC command line, before the -lcrypto. Since you are building against the OpenSSL headers under /usr/local/ssl, you also need to link against the actual library under the same prefix (even though you only appear to have a static one installed there, that may or may not be your intention; you may need to properly reinstall your OpenSSL built from source).
(edit) To fix the dlopen() and friends not being found by the linker, add -ldl into the GCC command line. -ldl tells the linker to also link against libdl.so, which is the shared library containing dlopen(), dlsym(), dlclose() etc.; these functions are used by OpenSSL internally and thus, -ldl is an indirect dependency when using -lcrypto (on Linux). Because you are linking to a static version of libcrypto, you need to explicitly link against all indirect dependencies.
If you are not familiar with linking to the proper libraries, I'd suggest you use OpenSSL as installed from your Operating System package manager; it might save you some trouble.
This might be relevant for people who tried to build their own openssl from source and then use it to compile other programs (in my case Git)
During configuration of openssl, add 'shared' option:
./config shared
This will create the required shared library libcrypto.so. You'll find more in the INSTALL file.
Also, if you run into this error during 'make'
"....can not be used when making a shared object
recompile with -fPIC
./config shared -fPIC
I'm using MinGW. I have some code which calls malloc and a few other general purpose functions. When I type:
gcc TestCode.c
I get an a.exe file, it works perfect, and I don't get any warnings.
If I type this:
gcc -c TestCode.c -o TestCode.o
ld *.o
I get a whole bunch of warnings such as:
TestCode.o:TestCode.c:(.text+0xa): undefined reference to `__main'
TestCode.o:TestCode:(.text+0x2e): undefined reference to `printf'
TestCode.o:TestCode:(.text+0x42): undefined reference to `_strerror'
TestCode.o:TestCode:(.text+0x69): undefined reference to `snprintf'
TestCode.o:TestCode:(.text+0x7e): undefined reference to `malloc'
TestCode.o:TestCode:(.text+0x93): undefined reference to `_strerror'
TestCode.o:TestCode:(.text+0xb1): undefined reference to `sprintf'
TestCode.o:TestCode:(.text+0xcf): undefined reference to `free'
I'm assuming this is an issue with how I'm calling the linker. As such, I'll only post the code if it isn't clear what the problem is. I'm hoping this is an easy fix and that I simply forgot to include some super obvious library when linking.
It appears that your ld doesn't link any libraries by default. From your error messages, it looks like you need at least the C runtime and libc. Use gcc to link to get some handy defaults linked in for you:
gcc -c TestCode.c -o TestCode.o
gcc *.o
If you really want to use ld directly, you're going to need to figure out the names of your C runtime library and libc. For example (assuming libraries named libcrt and libc):
ld *.o -lcrt -lc
As Carl Norum said, you can pass object files to gcc and it'll know it doesn't need to compile them - it just passes them on to the linker (whether or not you're compiling other source files in the same invocation).
And you should probably do that because there's a fair amount of detail that goes into linking in the CRT and windows support libraries (unless you have a very specific need to not use the default runtime). My current MinGW setup links in the following items along with my object files:
crt2.o
crtbegin.o
-ladvapi32
-lshell32
-luser32
-lkernel32
-lmingw32
-lgcc
-lmoldname
-lmingwex
-lmsvcrt
crtend.o
Use the --verbose option to see how gcc links for you.