SOLVED: Serious Problem: Corrupted libraries for sunxi cortexa7 in downloads.openwrt.org


#1

I want to compile usb thermometer for my sunxi cortexa7 OrangePiZero. The sources I successfully compiled already on A5V11 mipsel device and also on raspberypi.

The problem I experience now is that libusb-0.1.so installed by package liubusb-compat seems to have some problem. Though it is accepted and opened by linker it does not provide symbols. I looked into the libusb.so (renamed libusb-0.1.so) and the names of functions are inside. But command "nm" or "objdump" does not show any symbol table, not for static not for dynamic symbols.

Here is a piece of log I experience:
All undefined references below are inside library visible by hexeditor but not visible by nm or objdump.
look at -lusb below:

root@OpenWrt:/tempSRC/temperv14# make
gcc -DUNIT_TEST -O2 -ggdb -pipe -ffunction-sections -fdata-sections -mfloat-abi=hard -o temperv14 temperv14.c -L/tempSRC/temperv14 -lusb -Wl,--verbose=99 -Wl,--gc-sections -Wl,-rpath-link,/tempSRC/temperv14
.
.
.
.
attempt to open /tempSRC/temperv14/libusb.so succeeded
-lusb (/tempSRC/temperv14/libusb.so)
.
.
.
.
/tmp/ccacBfFv.o: In function `usb_detach':
/tempSRC/temperv14/temperv14.c:94: undefined reference to `usb_detach_kernel_driver_np'
/tmp/ccacBfFv.o: In function `find_lvr_winusb':
/tempSRC/temperv14/temperv14.c:175: undefined reference to `usb_open'
/tempSRC/temperv14/temperv14.c:177: undefined reference to `usb_busses'
/tmp/ccacBfFv.o: In function `setup_libusb_access':
/tempSRC/temperv14/temperv14.c:120: undefined reference to `usb_set_debug'
/tempSRC/temperv14/temperv14.c:122: undefined reference to `usb_init'
/tempSRC/temperv14/temperv14.c:123: undefined reference to `usb_find_busses'
/tempSRC/temperv14/temperv14.c:124: undefined reference to `usb_find_devices'
/tempSRC/temperv14/temperv14.c:139: undefined reference to `usb_set_configuration'
/tempSRC/temperv14/temperv14.c:146: undefined reference to `usb_claim_interface'
/tempSRC/temperv14/temperv14.c:151: undefined reference to `usb_claim_interface'
/tmp/ccacBfFv.o: In function `ini_control_transfer':
/tempSRC/temperv14/temperv14.c:192: undefined reference to `usb_control_msg'
/tmp/ccacBfFv.o: In function `control_transfer':
/tempSRC/temperv14/temperv14.c:212: undefined reference to `usb_control_msg'
/tmp/ccacBfFv.o: In function `interrupt_read':
/tempSRC/temperv14/temperv14.c:254: undefined reference to `usb_interrupt_read'
/tmp/ccacBfFv.o: In function `interrupt_read_temperatura':
/tempSRC/temperv14/temperv14.c:273: undefined reference to `usb_interrupt_read'
/tmp/ccacBfFv.o: In function `main':
/tempSRC/temperv14/temperv14.c:450: undefined reference to `usb_release_interface'
/tempSRC/temperv14/temperv14.c:451: undefined reference to `usb_release_interface'
/tempSRC/temperv14/temperv14.c:453: undefined reference to `usb_close'
collect2: error: ld returned 1 exit status
make: *** [Makefile:6: temperv14] Error 1
root@OpenWrt:/tempSRC/temperv14#

#2

I just had idea to check on Ubuntu X86 this command "file libusb.so" and it returns:

libusb.so: ELF 32-bit LSB shared object, ARM, EABI5 version 1 (SYSV), dynamically linked, corrupted section header size

is not this corrunted section header size problem??


#3

Can somobody "responsible" for downloads context verify situation and generate non-corupted libraries for sunxi device? Especially for libusb-compat as I need it :slight_smile:

thanx


#4

Please use the package system if you want to add something
https://openwrt.org/docs/guide-developer/packages


#5

The libraries hosted in the repository are processed by sstrip to reduce their size and thus cannot be used for linking, the C runtime dynamic loader is still able to use these shared objects though.

You either need to build libusb as well on device or use the OpenWrt SDK to properly cross compile your application using the unstripped staging libraries.


#6

Jow, thanx for answer.
But other libraries (also for ramips mipsel A5V11 device) are working well.
I can not believe that sstrip would cause "corrupted section header size" ? I think no normal process
can cause anyhow anything "corrupted"?
Or am I wrong?


#7

The "corrupted section header size" reported is indeed normal after a shared library has been treated with sstrip.


#8

Jow, thanx.
I downloaded SDK, unpacked it and simply searched for library in SDK folder. Yes, the one I found is not sstripped and everyting works with it!