Comment 8 for bug 1916278

Revision history for this message
William Page (datapath) wrote :

I have validated the following on Ubuntu 21.04 (vanilla, upgraded from 20.10, using the gnome DE instead of Ubuntu):

* The Arduino application fails while loading /usr/lib/x86_64-linux-gnu/ due to undefined symbol: sp_get_port_usb_vid_pid
* Running 'nm -D /usr/lib/x86_64-linux-gnu/' shows 'U sp_get_port_usb_vid_pid", meaning that that library depends on that symbol, but doesn't provide it
* Running 'ldd /usr/lib/x86_64-linux-gnu/' doesn't list any dependencies that provide the missing symbol
* Installing the package listserialportsc and running "listserialportsc" works
* Running 'nm -D /usr/bin/listserialportsc' also shows 'U sp_get_port_usb_vid_pid'
* Running 'ldd /usr/bin/listserialportsc' lists ' => /lib/x86_64-linux-gnu/ (0x00007f610efaa000)'
* Running 'nm -D /lib/x86_64-linux-gnu/' prints '0000000000002700 T sp_get_port_usb_vid_pid' indicating that that library provides the missing symbol
* Patching so that it specifies an ELF dependency on provides the missing symbol and allows the application to start as expected
* This patching can be performed by running 'sudo patchelf --add-needed' (recommended to back up the original library beforehand, e.g. sudo cp

Looking at the build scripts in the listSerialPortsC project, I suspect things were mis-translated going into the Ubuntu build process - the build scripts "vendor-in" the .c files with the required symbols rather than using a dynamic-link dependency on the library. If the debian package for liblistSerialsj is compiling the project sources without either adding -Lserialport to the compile/link line or vendoring in those sources, that would explain the issue.