L-Band Decoder error in Ubuntu 14

General Othernet Discussions
1

Hello to everyone involved with this worthwhile project.

As an I.T. professional and amateur radio operator who does a fair amount of satellite telemetry reception, I thought it would be interesting to purchase the patch antenna / LNA / SDR “DIY” kit to see if I could receive an L-Band signal.

Wanting to use existing computer resources, I found the “outernet-linux-lband” project on github and installed the various components.

Even though my location is not ideal (tree cover), I was pleased to get a signal lock with the “sudo demod-presets americas” command.

Unfortunately, when I run the “sudo decoder” command, the following error appears:

====================
ondd: relocation error: ondd: symbol ZNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEC1EPKcRKS3, version GLIBCXX_3.4.21 not defined in file libstdc++.so.6 with link time reference

Please note that the “alias decoder=‘sudo /usr/local/bin/decoder -o /srv/downloads -c /var/spool/ondd’” has been added to .bashrc.

… I have searched online but have not found a solution that made any difference. Not being a programmer, the exact meaning of this error is beyond my scope, but I am very experienced at locating solutions to issues such as this. However, I am not having any luck this time.

My system is Ubuntu 64-bit v14.04.01 with the following output from “uname -a”:

Linux k4kdr-linux 4.4.0-34-generic #53~14.04.1-Ubuntu SMP Wed Jul 27 16:56:40 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux

My compiler-related app versions are:

gcc (Ubuntu 4.8.4-2ubuntu1~14.04.3) 4.8.4

GNU Make 3.81

install (GNU coreutils) 8.21

… I do believe that the use of existing computers for Outernet would increase the number of people participating and discussing the project which of course is a good thing. If the decoder app will not run on my particular OS, that’s fine but I did not want to give up without asking here.

Thanks and best of luck with the project.

-Scott, K4KDR
Montpelier, VA USA

2

Hi Scott,

I received my kit today and just grabbed the code fresh from github. I seem to be having a similar issue myself on Ubuntu 14.04.4.

I forgot to actually bring the hardware home today, as it was delivered to my office, but I thought I’d deal with the software tonight and try the hardware tomorrow.

I didn’t bother running with root privileges, as I didn’t expect it to work anyway, without the hardware. It would be good to avoid that need altogether to be honest. None of my other SDR hardware (FCD, USRP, ANAN, RTL) has software that actually requires such permissions!

Anyway, I’m seeing the following results.

darren@betty:~$ /usr/local/bin/ondd -V -D ~/ondd/var/run/ondd.data -c ~/ondd/cache -O ~/ondd/date/
/usr/local/bin/ondd: /usr/lib/x86_64-linux-gnu/libstdc++.so.6: version `CXXABI_1.3.8' not found (required by /usr/local/bin/ondd)
/usr/local/bin/ondd: /usr/lib/x86_64-linux-gnu/libstdc++.so.6: version `GLIBCXX_3.4.21' not found (required by /usr/local/bin/ondd)
darren@betty:~$ ldd /usr/local/bin/ondd
/usr/local/bin/ondd: /usr/lib/x86_64-linux-gnu/libstdc++.so.6: version `CXXABI_1.3.8' not found (required by /usr/local/bin/ondd)
/usr/local/bin/ondd: /usr/lib/x86_64-linux-gnu/libstdc++.so.6: version `GLIBCXX_3.4.21' not found (required by /usr/local/bin/ondd)
    linux-vdso.so.1 =>  (0x00007ffd28b31000)
    librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1 (0x00007f0af62c0000)
    libcrypto.so.1.0.0 => /lib/x86_64-linux-gnu/libcrypto.so.1.0.0 (0x00007f0af5ee4000)
    libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x00007f0af5cca000)
    libstdc++.so.6 => /usr/lib/x86_64-linux-gnu/libstdc++.so.6 (0x00007f0af59c6000)
    libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007f0af57b0000)
    libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f0af53ea000)
    libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007f0af51cc000)
    libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007f0af4fc8000)
    libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007f0af4cc1000)
    /lib64/ld-linux-x86-64.so.2 (0x0000560e7470e000)
darren@betty:~$ uname -a
Linux betty 4.4.0-36-generic #55~14.04.1-Ubuntu SMP Fri Aug 12 11:49:30 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux
darren@betty:~$

I’ll see if I can figure out a workaround.

Cheers,

Darren, G0HWW

3

I followed these instructions to upgrade to gcc 4.9 …

sudo add-apt-repository ppa:ubuntu-toolchain-r/test
sudo apt-get update
sudo apt-get install gcc-4.9 g++-4.9
sudo update-alternatives --install /usr/bin/gcc gcc /usr/bin/gcc-4.9 60 --slave /usr/bin/g++ g++ /usr/bin/g++-4.9

From here and I now get the same problem that you have reported.

Cheers,

Darren, G0HWW

4

Ha. Well I have a work around, but I think the proper solution is for the devs to build these binaries with an older toolchain, provide a compatible libstdc++.so in their distribution, or statically link it in.

My work around might not be easily recreated. I concluded that I needed a more modern libstdc++.so than I could easily obtain. I ran “locate libstdc++.so” and found that I had quite a few versions of libstdc++.so installed by games I’d bought with Steam. I mulled over the bunch of directories and picked the path for the most recent game I had installed, recalling that it only supported x86_64.

I then let rip with LD_PRELOAD ,

darren@betty:~/src/outernet-linux-lband$ LD_PRELOAD=/home/darren/.steam/SteamApps/common/WormsWMD/lib/libstdc++.so.6 /usr/local/bin/ondd -V -D ~/ondd/var/run/ondd.data -c ~/ondd/cache -O ~/ondd/date/
00:30:22.186 [main] Unable to load config: /etc/ondd.conf (null)
00:30:22.186 [main] v2.2.0
00:30:22.187 [main] thread exception: bind() failed: (98) Address already in use

Worms WMD FTW!

If you too have got Worms WMD, or a bunch of other things that ship with their own libstc++.so files, then you can play library roulette. I guessed right first time :slight_smile:

Good luck. Now to read more of TFM and figure out what to do next. Happy hacking!

Cheers,

Darren, G0HWW

5

Can’t thank you enough for looking into this, Darren.

Here is what I get with the “locate” comand:

k4kdr:~$ locate libstdc++.so
/usr/lib/gcc/x86_64-linux-gnu/4.8/libstdc++.so
/usr/lib/gcc/x86_64-linux-gnu/4.9/libstdc++.so
/usr/lib/x86_64-linux-gnu/libstdc++.so.6
/usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.22

… so I tried each one with the LD_PRELOAD command in front of the ondd executable and got the same error. I was curious what date info might show on those 4 file matches, but when I ran an “ls -l” on each of them, they all seem to link to the same file. So, I suppose this means I actually ran the same command with each of my attempts.

Yes, it certainly would be a great help if the software could include the correct version of any dependencies, but linux isn’t very well known for that kind of thing, is it?

I don’t know if it’s possible to randomly use imported files of this type across systems, but by chance could I get a copy of the libstc file that worked for you? If it’s as simple as that, of course.

Regardless, thanks so much for your research and work-around. Perhaps your efforts will lead to an update or other solution from the developers.

-Scott

6

Have sent an email with the lib in Scott. Hopefully google found a good address for you in the AMSAT mailing list.

Darren, G0HWW

7

I have the demod and decoder working now, with the libstdc++.so from Worms W.M.D. :slight_smile:
Now I just need to conjure up a line of sight and a few dBs of SNR. I have seen a few “detects” but mostly just “search” in my first and admittedly utterly unexpected to work attempts so far in my lounge with about 0 +/- 1 dB SNR and -107dBm RSSI reported.
If all else fails I have currently unused 1.2m satellite dish lying around in the “dining room”, some bamboo and duct-tape so I’m sure I can get a usable signal one way or another :slight_smile:

Cheers,

Darren, G0HWW

8

Thanks to help from Darren, I can confirm that the decoder script (which runs ONDD) will start successfully as long as it is pointed to a compatible libstdc++.so.6 file.

The syntax that worked for me is:

LD_PRELOAD=/usr/local/lib/libstdc++.so.6 ondd -V -D /var/run/ondd.data -c /var/spool/ondd -o /srv/downloads

… I realize that variables are preferable in linux scripts, but when I ran the default decoder script (with the addition of the LD_PRELOAD portion, I noticed that a “ps -ef|grep ondd” showed that the actual command that was running pointed both -c and -o to the same folder. Instead of trying to clear that up, I just hard-coded the folder destinations in that final command line as shown above. Others may wish to cross-check the result of any working decoder script with a ps command to verify that the desired net result is being achieved.

In regard to signal, I have temporarily placed the antenna, LNA, and SDR outside and have shown a status of “CODE LK” for several hours. Nothing yet in either of the destination folders, but then again I don’t know if anything is being sent. Also, my SNR is marginal so even if there is data being broadcast, it remains to be seen whether or not I will achieve any successful downloads.

Nevertheless, I wanted to see if I could get this far and thanks to Darren, I have what would appear to be a working setup in Ubuntu 14.04.

-Scott, K4KDR
Montpelier, VA USA

9

Wow, things have been fixed in the git repo pretty swiftly.

It looks like:

  1. Don’t need to run with root perms any more after installation
  2. The ondd binary is now built with gcc 4.8

So it doesn’t need any faffing around with LD_PRELOAD now. Furthermore, I just installed the new version on another Linux box, running Ubuntu 12.04 LTS (Precise) on x86_64 with kernel 3.2.0 and it works on that now too without any faffing :slight_smile:

10

Oh, forgot to mention that I ran a 10m USB extension cable to my front door last night and pointed the patch at the right bit of sky. Despite the overhead telephone line and street-light I managed to get about 5dB SNR and 0.01 SER and status"CODE LK" for a couple of hours until I went to bed, but no sign of CRC passes or CRC failures, or any kind of data transfer, which pretty much matches what Scott saw.

UPDATE: Entire kit was taped to a bamboo stick, sealed in a ziploc bag, taped up, sealed with self-amalgamating tape around the bag, USB extension and bamboo and shoved ouf of my upstairs sash window, with the end of the stick lashed to a handy tripod and using a Ubuntu 12.04 x86_64 laptop.

Now RSSI -99.5dB, SNR 9.5dB, SER 0, CODE LK and zero for both CRC OK and CRC Errs. Will see what happens next.