Client install issue

I’m using the Raspbian 2015-05-05 image on a pi2. I was following this doc - http://satnogs.readthedocs.org/client/raspi2-install.html

The client install failed.
sudo pip install satnogsclient==0.2.3

This was the error:

    arm-linux-gnueabihf-gcc -pthread -DNDEBUG -g -fwrapv -O2 -Wall -Wstrict-prototypes -fno-strict-aliasing -D_FORTIFY_SOURCE=2 -g -fstack-protector-strong -Wformat -Werror=format-security -fPIC -Ilibastro-3.7.5 -I/usr/include/python2.7 -c extensions/_libastro.c -o build/temp.linux-armv7l-2.7/extensions/_libastro.o

cc1: error: unrecognized command line option ‘-fstack-protector-strong’

error: command 'arm-linux-gnueabihf-gcc' failed with exit status 1

So I grabbed a copy from git and it failed as well.

Processing pyephem.git@47d0ba3616ee6c308f2eed319af3901592d00f70
Writing /tmp/easy_install-whzQj5/pyephem.git@47d0ba3616ee6c308f2eed319af3901592d00f70/setup.cfg
Running setup.py -q bdist_egg --dist-dir /tmp/easy_install-whzQj5/pyephem.git@47d0ba3616ee6c308f2eed319af3901592d00f70/egg-dist-tmp-nRkQ3x
cc1: error: unrecognized command line option ‘-fstack-protector-strong’
error: Setup script exited with error: command 'arm-linux-gnueabihf-gcc' failed with exit status 1

Any ideas?

Hey Steve,

I don’t expect this to fix your issue, but 0.2.4 did release just a couple of hours ago so I would suggest against pinning to 0.2.3

(I’ll try reproducing this tomorrow, I’m traveling today and not near my raspi collection)

one more question while I’m thinking of it - did you do a sudo apt-get update; sudo apt-get upgrade on the install?

When you run ‘python’ what GCC does it say it was built with, and what does ‘gcc --version’ say?

After some research this looks like an issue with your envs gcc version. Specifically -fstack-protector-strong was introduced after gcc 4.9.x and prior versions couldn’t recognize this flag.

The first thing I did after booting the new image was run update and upgrade. It took a while.

I had to run an errand, but a quick search suggests the issue may be related to the different gcc versions.

python
Python 2.7.9 (default, Mar 8 2015, 00:52:26)
[GCC 4.9.2] on linux2

gcc --version
gcc (Debian 4.6.3-14+rpi1) 4.6.3

That’s odd. When I wrote the docs I did an update too, I’ll have to check it and try again. They should not be mismatched like that, must be a problem in raspbian

I think I know what happened. When I first installed the rtl_sdr I was having issues with seg faults running rtl_tcp whenever I closed the connection in the client. Updating the libusb-1.0 from deb http://archive.raspbian.org/raspbian jessie main fixed the issue, but this also is the repository that was used when I installed the packages from your instructions. I forgot to remove it. Fun stuff. I may push the rest of the OS to jessie and see how it runs before I re-image it back. Thanks

Ahhh yeah…

coincidentally I have a second raspi2 I’m working on using for satnogs running jessie… (mostly because I’m testing a gnuradio+funcube dongle setup as a replacement for rtl_fm+rtl_sdr, and that will be much easier in jessie)

So far everything satnogs-wise works in jessie, the only issue being that jessie is a bit more advanced to get running. If you choose to do that I’d recommend starting with this image from this post rather than trying to bring raspbian up to jessie.

I figured I’d play with jessie on another pi. I think I have another one laying around that’s not already doing something. I re-imaged and everything installed just fine, although the segfaults are back with rtl_tcp. Maybe I’ll try the libusb from jessie again since it fixed it before.

shouldn’t be segfaulting with the default libs… are you using the satnogs fork of the rtl_sdr package?

I’m stuck on a plane for the next hour or more, feel free to catch me on irc (cshields) on #satnogs and bounce ideas

I never installed the original rtl software in this build. I walked down the install doc. I’ve seen other posts about the same issue, which is how I found the fix for the segfaults. I’ll play around with it later.

Ok I’ll try to reproduce… @oe6rke just recently installed the same and I don’t believe he had this issue (highlighting him here to see if that was the case?)

I’m using one of the newer R820T2 dongles from NooElec. I’ll try to reproduce it with one of the older ones. I haven’t dug that far into the Satnogs software, so I don’t know if rtl_tcp is relied upon. If it isn’t then most likely the problem wouldn’t be encountered.

Switching to the jessie libusb would require also updating far too many of of the critical libraries, like libc and libc6. There’s a higher chance of other things breaking. At that point I might as well move to jessie. I’ll pickup another SD and try jessie while I do some searching on alternative fixes for wheezy.

I guess I didn’t need to dig quite so far. Apparently it’s still an issue.

i had no issues compiling the RTL_fm a fews days ago. Os were ubuntu 64 bits 14 lts Server version.
just with multimon i had some negotions, but with
sudo apt-get install qtcreator i met the baseline für qt4-make

br Robert