I just installed dfu-util V0.11 because running dfu-util V0.9 was failing with a file-size problem when I tried to upload rootfs to my embedded device (TI AM62x is base).
I followed the build instructions (Ubuntu 22.04 is my host OS), made sure lbusb-dev was version 1.0.0, now I get the following when I run "dfu-util -l":
dfu-util -l
dfu-util: symbol lookup error: dfu-util: undefined symbol: libusb_set_option
I noticed this was an issue for an older version of dfu-util, I was wondering if I missed something during install or if a new dependency was missed?
Anonymous
It could be that you are building against one version of libusb and then run-time linking against another version. To start with, make sure you are running the correct dfu-util binary:
type dfu-utilYou said you built dfu-util 0.11 but did you install it, and where? /usr/local/bin ?
Then run ldd on that file, e.g.
ldd /usr/local/bin/dfu-utilThis will list which libusb .so file will be run-time linked.
Typical candidates for confusion would be a custom-installed libusb in /usr/local/lib in addition to the distro-installed (e.g. /lib/x86_64-linux-gnu/libusb-1.0.so.0).
I followed the build manual on the dfu-util site. I already had
libusb-1.0.0-dev installed. I did install dfu-util executable into
/usr/local/bin.
After running ldd:
ldd /usr/local/bin/dfu-util
linux-vdso.so.1 (0x00007ffee19ad000)
libusb-1.0.so.0 => /usr/local/lib/libusb-1.0.so.0 (0x000073d5ada00000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x000073d5ad600000)
libudev.so.1 => /lib/x86_64-linux-gnu/libudev.so.1 (0x000073d5adcb8000)
libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0
(0x000073d5adcb3000)
/lib64/ld-linux-x86-64.so.2 (0x000073d5add18000)
I added /usr/local/bin to my PATH.
which result:
which dfu-util
/usr/local/bin/dfu-util
Now I try dfu-util;
dfu-util -l
dfu-util: symbol lookup error: dfu-util: undefined symbol: libusb_set_option
So, then I removed and added back libusb-1.0-0-dev:
sudo apt remove libusb-1.0-0-dev
sudo apt updatesudo apt install libusb-1.0-0-dev
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
The following NEW packages will be installed:
libusb-1.0-0-dev
0 upgraded, 1 newly installed, 0 to remove and 3 not upgraded.
Need to get 76.3 kB of archives.
After this operation, 323 kB of additional disk space will be used.
Get:1 http://us.archive.ubuntu.com/ubuntu jammy-updates/main amd64
libusb-1.0-0-dev amd64 2:1.0.25-1ubuntu2 [76.3 kB]
Fetched 76.3 kB in 0s (679 kB/s)
Selecting previously unselected package libusb-1.0-0-dev:amd64.
(Reading database ... 324424 files and directories currently installed.)
Preparing to unpack .../libusb-1.0-0-dev_2%3a1.0.25-1ubuntu2_amd64.deb ...
Unpacking libusb-1.0-0-dev:amd64 (2:1.0.25-1ubuntu2) ...
Setting up libusb-1.0-0-dev:amd64 (2:1.0.25-1ubuntu2) ...
Re-run dfu-util:
dfu-util -l
dfu-util: symbol lookup error: dfu-util: undefined symbol: libusb_set_option
Last edit: Tormod Volden 2024-08-06
Exactly, your dfu-util binary is run-time linking a libusb in /usr/local/bin:
libusb-1.0.so.0 => /usr/local/lib/libusb-1.0.so.0 (0x000073d5ada00000)This is not the libusb that comes with the distro as part of libusb-1.0-0-dev, and which is referenced during building. Hence the mismatch when running dfu-util.
Simply delete the (apparently very) old libusb that you have in /usr/local/lib.
Thanks so much, this solved the problem and I am now able to send the
rootfs.ext4 file, but u-boot is rejecting it now (not dfu-util issue at
this point). I think we can safely close this ticket.
Last edit: Tormod Volden 2024-08-11
It is happening again and I have not touched a thing. I rebooted my
laptop, and tried to use dfu-util again.
sudo dfu-util -l
dfu-util: symbol lookup error: dfu-util: undefined symbol: libusb_set_option
ldd output:
sudo ldd /usr/local/bin/dfu-util
linux-vdso.so.1 (0x00007ffed54f7000)
libusb-1.0.so.0 => /usr/local/lib/libusb-1.0.so.0 (0x000073306e600000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x000073306e200000)
libudev.so.1 => /lib/x86_64-linux-gnu/libudev.so.1 (0x000073306e9b2000)
libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0
(0x000073306e9ad000)
/lib64/ld-linux-x86-64.so.2 (0x000073306ea12000)
I removed the offending /usr/local/lib/libusb-1.0.so.0 & it worked again.
I was wondering if you've ever run into this before?
Thanks!
Last edit: Tormod Volden 2024-08-11
So the /usr/local/lib/libusb-1.0.so.0 that you deleted showed up again after reboot? No, I have never run into this before. Maybe you have a boot script installing it, or a file syncing service that reinstates it.
I have no idea, but it has not happened again since I last reported the anomaly.