0.2.7 linking fail

[rskunath]

I did manage (thanks for the help) to work through my previous issues by upgrading my local build of liquid-dsp to version 1.4 and supplying the devel for libjpeg8. But after that I still get the linking failure below, and don't know how to proceed from here?

Any ideas are greatly appreciated.

/usr/lib64/gcc/x86_64-suse-linux/11/../../../../x86_64-suse-linux/bin/ld: CMakeFiles/CubicSDR.dir/src/modules/modem/ModemDigital.cpp.o: in function ModemDigital::updateDemodulatorLock(modemcf_s*, float)': ModemDigital.cpp:(.text+0xde): undefined reference tomodemcf_get_demodulator_evm' collect2: error: ld returned 1 exit status make[2]: [CMakeFiles/CubicSDR.dir/build.make:1466: x64/CubicSDR] Error 1 make[1]: [CMakeFiles/Makefile2:84: CMakeFiles/CubicSDR.dir/all] Error 2

[fventuri]

Rick, if you run make VERBOSE=1 you should be able to see the full command run by the ld linker there and see where it pulls the liquid DSP shared library from. Assuming that it links with say /usr/local/lib64/libliquid.so (your path there might be different), then run this command:

    nm /usr/local/lib64/libliquid.so  | grep modemcf_

to see if any modemcf_ symbol is there (including modemcf_get_demodulator_evm).

73, Franco K4VZ

[rskunath]

Thanks Franco.

On:

|nm /usr/local/lib64/libliquid.so | grep modemcf_ |

It is in there:

00000000000d0bc8 T modemcf_get_demodulator_evm

And |

/usr/local/lib64/libliquid.so is the path.|

Rick Kunath, K9AO

[fventuri]

Rick, very strange!

I just rebuilt the latest version of CubicSDR with make VERBOSE=1, and I noticed the following in the link command:

... -L/usr/local/lib  -Wl,-rpath,/usr/local/lib:/usr/local/lib64: -lliquid -L/usr/local/lib ...

I also rebuilt the latest version of liquid DSP from scratch and when I ran sudo make install here, it installed itself under /usr/local/lib (as opposed to /usr/local/lib64); I went ahead and I moved it to the right location, but I am now wondering if you might have an older copy of that shared library under /usr/local/lib (if you do, I would rename/remove it, and rerun sudo ldconfig to make sure the linker picks up the version under /usr/local/lib64).

Franco K4VZ

[rskunath]

Nothing fron liquid is in /usr/local/lib b ut in usr/local/lib64 I have libliquid.so and libliquid.a and both have the date stamp of a couple of days ago when I did a frean git c;lone and built the package again.

Any ideas why they're not found, if that's the issue?

Here is the stuff around it:

-lfontconfig -lfreetype -lgthread-2.0 -lX11 -lXxf86vm -lSM -lnotify -lpng -lz - ljpeg -ltiff -lwxregexu-3.1 -lz -ljpeg -ltiff -lwxregexu-3.1 -ldl -lm -lGL -lGLU /usr/local/lib64/libliquid.so -ldl -lpulse-simple -lpulse -pthrea d

Rick K9AO

[fventuri]

Rick, everything looks correct - perhaps there's a cache somewhere that has still the old file; not really sure (here on Fedora, I see that the command used by the linker is actually /usr/lib64/ccache/c++, which keeps a cache of the compiled objects under ~/.ccache, but I am not sure if it also applies to shared libraries).

I also found this page: https://elinux.org/GCC_Tips with a few things to try; since when you ran make VERBOSE=1 earlier, it should have shown you the full linker command run by make, you may want to try adding the -Wl,-t option to enable tracing (see the section 'See what Files the Linker is Using') in case it shows something interesting.

Franco K4VZ

[rskunath]

I really appreciate the help on this Franco :)

Much progress. And I have CubicSDR version 0.2.7 running now.

I dug into the liquid libs and I did have libliquid 1.3.2 from the distro installed. That was in /usr/lib64 as it should have been and the locally built libliquid version was in the /usr/local/lib64. So the linker should have been able to keep those separate and use the locally built version first, if found. But it didn't. I had installed libliquid when I was testing a barely usable spectrum analyzer app so I just uninstalled both and just to be really safe rebuilt libliquid again.

Progress, now CubicSDR compiled and linked.

However it segfaulted instantly on launch. I ran it in gdb and did a backtrace and saw farther down the trace listing a few references to WX Widgets. This was already at the latest 3.1.5 version from last year, but I figured heck, lets rebuild that too.

I did that and CubicSDR launched right up.

So all in all, nothing really wrong anywhere in the CubicSDR code, there was an oddity with the linker, and something unknown about my supposed same WX Widgets 3.1.5 ersion.

But, hopefully things are cleaned up a bit better now. That's the most I have had to dig in building stuff in a while, but worth it.

Thanks again Franco for your help and getting me pointed at the problem.

Rick Kunath, K9AO

[vsonnier]

Since it was a user config error, now solved , I close this issue.