i am using Xilinx SDK with cross compiler as aarch64-none-elf-gcc
i am loading a shared library in my program and i am getting error as
Building target: fsbl.elf
Invoking: ARM v8 gcc linker
aarch64-none-elf-gcc -L"/proj/ssw_xhd/boot/balakrish/workspace/hello_world/Debug" -Lwrk/released/2017.3/GA/2017.3_1005_1/installs/lin64/SDK/2017.3/gnu/aarch64/lin/aarch64-none/bin/../lib/gcc/aarch64-none-elf/6.2.1/../../../../aarch64-none-elf/bin/ld -Wl,-T -Wl,../src/lscript.ld -L../../fsbl_bsp/psu_cortexa53_0/lib -o "fsbl.elf" ./src/psu_init.o ./src/xfsbl_authentication.o ./src/xfsbl_board.o ./src/xfsbl_bs.o ./src/xfsbl_csu_dma.o ./src/xfsbl_dfu_util.o ./src/xfsbl_exit.o ./src/xfsbl_handoff.o ./src/xfsbl_hooks.o ./src/xfsbl_image_header.o ./src/xfsbl_initialization.o ./src/xfsbl_main.o ./src/xfsbl_misc.o ./src/xfsbl_misc_drivers.o ./src/xfsbl_nand.o ./src/xfsbl_partition_load.o ./src/xfsbl_plpartition_valid.o ./src/xfsbl_qspi.o ./src/xfsbl_rsa_sha.o ./src/xfsbl_sd.o ./src/xfsbl_translation_table.o ./src/xfsbl_usb.o -lhello -Wl,--start-group,-lxil,-lgcc,-lc,--end-group -Wl,--start-group,-lxilffs,-lxil,-lgcc,-lc,--end-group -Wl,--start-group,-lxilsecure,-lxil,-lgcc,-lc,--end-group -Wl,--start-group,-lxilpm,-lxil,-lgcc,-lc,--end-group -n
/tmp/ccjtx6CQ.ltrans0.ltrans.o: In function `main':
<artificial>:(.text.startup+0x18c): undefined reference to `dlopen'
<artificial>:(.text.startup+0x18c): relocation truncated to fit: R_AARCH64_CALL26 against undefined symbol `dlopen'
<artificial>:(.text.startup+0x19c): undefined reference to `dlsym'
<artificial>:(.text.startup+0x19c): relocation truncated to fit: R_AARCH64_CALL26 against undefined symbol `dlsym'
<artificial>:(.text.startup+0x1a4): undefined reference to `library_function'
<artificial>:(.text.startup+0x1a4): relocation truncated to fit: R_AARCH64_CALL26 against undefined symbol `library_function'
<artificial>:(.text.startup+0x1ac): undefined reference to `dlclose'
<artificial>:(.text.startup+0x1ac): relocation truncated to fit: R_AARCH64_CALL26 against undefined symbol `dlclose'
collect2: error: ld returned 1 exit status
make: *** [fsbl.elf] Error 1
Finally my question is how to load -ldl in cross compiling
if i use -ldl in C/C++ Build settings-.libraries->library paths . I am getting error as
/wrk/released/2017.3/GA/2017.3_1005_1/installs/lin64/SDK/2017.3/gnu/aarch64/lin/aarch64-none/bin/../lib/gcc/aarch64-none-elf/6.2.1/../../../../aarch64-none-elf/bin/ld: cannot find -ldl
collect2: error: ld returned 1 exit status
make: *** [fsbl.elf] Error 1
Different parts of your answer seem to conflict.
dlopen, dlsym and friends are used to load code from another file on the filesystem. In other words, these functions are related to loading code, at runtime, from a library available on the target platform filesystem and operating system.
In the case of cross compiling, the toolchain needs to provide the library (libdl.so or libdl.a) that has the implementaiton of those functions. The toolchain provide the code that has the relevant operating system calls to open the file with the code, map it to memory and link it into the running program.
Which is where the conflict comes into play. The toolchain you mention seems to be bare metal toolchain. In other words, this is a tool chain for running your code directly on the chip, with no operating system. If you have no operating system, it should be obvious that you cannot use it in order to load further code at runtime.
With that in mind, it should be obvious why the tool chain does not supply you with a suitable implementation of libdl.a. It cannot be generically implemented on the platform.
Related
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 am compiling a hello world program in C on a 64-bit Linux machine. I am using a GCC ARM embedded toolchain to cross compile my program on a FOX G20 V board with an ATMEL AT91SAM9G20 processor.
On the first take, I had a few errors when compiling because the program didn't recognize the printf, return etc. functions (the standard C functions). So I decided to make the link between the functions, which I believe are defined in the libc.a library (correct me if I'm wrong), by doing arm-none-eabi-gcc -o hello hello.c libc.a but the outcome still results in errors:
libc.a(lib_a-exit.o): In function `exit':
exit.c:(.text.exit+0x16): undefined reference to `_exit'
libc.a(lib_a-sbrkr.o): In function `_sbrk_r':
sbrkr.c:(.text._sbrk_r+0xc): undefined reference to `_sbrk'
libc.a(lib_a-writer.o): In function `_write_r':
writer.c:(.text._write_r+0x10): undefined reference to `_write'
libc.a(lib_a-closer.o): In function `_close_r':
closer.c:(.text._close_r+0xc): undefined reference to `_close'
libc.a(lib_a-fstatr.o): In function `_fstat_r':
fstatr.c:(.text._fstat_r+0xe): undefined reference to `_fstat'
libc.a(lib_a-isattyr.o): In function `_isatty_r':
isattyr.c:(.text._isatty_r+0xc): undefined reference to `_isatty'
libc.a(lib_a-lseekr.o): In function `_lseek_r':
lseekr.c:(.text._lseek_r+0x10): undefined reference to `_lseek'
libc.a(lib_a-readr.o): In function `_read_r':
readr.c:(.text._read_r+0x10): undefined reference to `_read'
collect2: error: ld returned 1 exit status
I'm really unsure as to why the program still does not recognize the standard functions even though I've linked the library to the application. If anyone has a reason as to why, or a solution as to how I can fix this problem, I would be very grateful.
UPDATE
I've downloaded the glibc library from here. I've compiled and created a static library from the syscalls.c library that I found in newlib-2.1.0/libgloss/arm and when I link the library to my application code, I still get the same error.
Try executing this:
arm-none-eabi-gcc --specs=rdimon.specs -lgcc -lc -lm -lrdimon -o hello hello.c
Your toolkit seems to provide the librdimon.a, a library which provides the basic standard C functions.
I got this error because my binary cannot fit the ROM.
My first error was:
address 0x34000 of arm_flash.elf section `.mmu_tbl' is not within region `ps7_ram_0`
Then I've got the same list of undefined reference errors.
I need to reduce the binary size, by removing new keywords, and all dynamic memory allocation from my C++ code.
I'm writing a simple C shared library using Eclipse CDT under Linux 64bit.
The code has one reference to the rand() function in the <stdlib.h> It compiles fine but when linking it reports the following error from the linker:
gcc -shared -o "libalg.so" ./sort.o
/usr/bin/ld: ./sort.o: relocation R_X86_64_PC32 against undefined symbol `rand##GLIBC_2.2.5' can not be used when making a shared object; recompile with -fPIC
/usr/bin/ld: final link failed: Bad value
sort.o is the object file compiled from the file. libalg.so is the target shared library name.
Can anyone explaining why this happen?
Thanks.
On x86_64 architecture gcc requires you to use -fPIC i.e Position Independent Code by default.
The underlying reason for the error is that the relocation type for the symbol rand is of type R_X86_64_PC32 which means that it is PC relative and should lie within 32bit offset from the following instruction.
But the current architecture is of x86_64 type which means that it can lie anywhere within the 64bit address space.
So the dynamic linker actually can not link a symbol with such a relocation type.
Either you have to use -fPIC or compile your code using the -mcmodel=large which will actually make the relocation type to R_X86_64_64.
For more details on how linking is done refer to this great blog by Eli Bendersky
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.
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