lqcustomplot 2.0 / 2.1 on Ubuntu ARM 23.04

Installation Help
1

Please provide the following information with your question:

  1. Operating System: Ubuntu 23.04 (ARM)
  2. Method of download attempted (from wfview.org, package manager, source code, etc): compiling via Debian Build Script
  3. Radio Model: IC-7300
  4. Method of radio connectivity (USB, WiFi, Ethernet, etc): USB
  5. Did you check the FAQ and read the manual? Yes

Decided I would try upgrading my distro today to Ubuntu 23.04. After the upgrade I could no longer run wfview on the system with it throwing the error “wfview: error while loading shared libraries: libqcustomplot.so.2.0: cannot open shared object file: No such file or directory”. It appears libqcustomplot is now at version 2.1. So I went to re-compile with version 2.1 installed. During the compile, the following error is thrown:

/usr/bin/ld: cannot find -lqcustomerplot: No such file or directory

Full log: https://termbin.com/l1ew

Thank you for any assistance!

1 Like
2

Can you see if you can install libqcustomplot using apt?

My guess is that it is installed and you’ve hit the version of Ubuntu where the library has mixed case in the name.

I can guide you through fixing this up in the morning.

—E
de W6EL

3

Thank you @eliggett I appreciate it. I did double check that libqcustomplot2.1 and the libqcustomplot-dev are installed. I also tried to install the 2.0 version manually without success.

I do find libQCustomPlot.so in /usr/lib/aarch64-linux-gnu.

I appreciate the help!

4

Going off your direction around case sensitivity, I created a symlink to /usr/lib/aarch64-linux-gnu/libQCustomPlot.so where it is all lower case and the compile completed successfully!

Would it be useful if I submitted a bug report in the Git repo?

5

Hi Dustin.

No we are well aware of this issue, unfortunately somebody at Debian decided it would be a good idea to rename the libqcustomplot library to libQCustomPlot in the latest version. This means that going forward, new versions of Debian derived operating systems (like Ubuntu) will get this change.

Unfortunately as you have discovered, it breaks our make process. We are currently looking at a more permanent solution that will continue to work for all existing installations as well as new ones (without needing to create a symlink).

73 Phil M0VSE

6

Hi Dustin.

I had an idea about how we can fix this, and that is now pushed to master. The downside of this fix, is that it will likely break compiling for you (as it will detect both filenames). If you pull the latest master, you are best to delete the symlink that you created.

Thanks

73 Phil

7

No worries, I removed the symlink and re-ran the compile with success. I’m having some audio issues now, so I’ll work through that. But I appreciate the help!

8

Thanks Phil for the fix. Now able to run the script in Debian Testing!