Closed edaniszewski closed 10 years ago
so i tried this on ubuntu, intel
sudo apt-get install gcc-4.4
fresh clean tarball of sources
cd srtnver3
change "gcc" to "gcc4-4" on the uncommented compile line. no need to add gtk+2.0 to the stuff at the end either.
./srtnmake
builds with just three warnings, one from rot2 regarding ignoring return value of 'system', and two from srthelp.c about ignoring the results of 'fgets'
again, can't test without a rotator controller, but that is eerie, and would support the hypothesis above...
gcc4-4.. thats fun..
I was planning on going in to the lab tomorrow morning to do some work on it. I'll try building with what we have currently, now that the controller doesn't have limits, and see how that goes, then try with gcc4-4 and see what those results are.
It seems that it works on Ubuntu (EDIT: I just realized, it works with our version of the code, not a clean install. I will try a clean install srtn now), with no extra work required, the only change being that the controller has no limits set. The max/min readout looked good--about the same as when simulated, and I was able to get the rotator to move when changing the az el from within srtn.
when compiling, however, many warning messages still persisted.
With a fresh, clean tar xzvf:
gcc could not compile as it needed gtk+-2.0 in the compile command. If gtk+-2.0 is added, then it compiles fine (still with warnings though) and is able to run with the dongle, but once the rotator is unsimulated, it has a buffer overflow ):
gcc-4.4 could compile without the gtk+-2.0 only returning a few warnings (consistent with what @acencini mentioned before) and is able to run with the dongle unsimulated, but again, when the rotator is unsimulated, a buffer overflow occurs.
so in all cases ubuntu is still not working? i am confused between this and the previous comment ... thanks for investigating this!
On Sat, Apr 5, 2014 at 10:05 AM, Erick Daniszewski <notifications@github.com
wrote:
With a fresh, clean tar xzvf:
gcc could not compile as it needed gtk+-2.0 in the compile command. If gtk+-2.0 is added, then it compiles fine (still with warnings though) and is able to run with the dongle, but once the rotator is unsimulated, it has a buffer overflow ):
gcc-4.4 could compile without the gtk+-2.0 only returning a few warnings (consistent with what @acencini https://github.com/acencini mentioned before) and is able to run with the dongle unsimulated, but again, when the rotator is unsimulated, a buffer overflow occurs.
Reply to this email directly or view it on GitHubhttps://github.com/BenningtonCS/Telescope-2014/issues/72#issuecomment-39639271 .
Sorry for the confusion! This is how it stands:
compiler | srtn build | compilation notes | works with unsimulated rotator? |
---|---|---|---|
gcc | clean srtnver3 | needs 'gtk+-2.0' added, many warnings | no |
gcc | our github hosted srtn | needs 'gtk+-2.0' added, many warnings | yes |
gcc-4.4 | clean srtnver3 | few warnings | no |
So if we've got the code working on Ubuntu, should we close this issue (maybe open a new one regarding further investigation of what's actually happening on the Ubuntu side?)
We can probably close this one soon and then open another to do investigation on Ubuntu.. but first I want to make sure we can get it to work from a clean version, so going in, changing buffer sizes, seeing if that fixes it. It seems likely that those changes are why our version works, but lets be sure before we say we can get it to work.
i think we can close this though we should capture that awesome table in our documentation
some more notes on my experiments that may be relevant/troubling...
i was curious as to what was going on with centos that made it so ... different. turns out gcc 4.4 or thereabouts is shipped with centos. that's OLD.
hmm.
so i installed a newer version of gcc: http://people.centos.org/tru/devtools-1.1/readme
in this case, 4.7.x
and then built srtn. interestingly, i got the slew of warnings that we didn't get with 4.4, though the UI does launch (but i am operating in simulated mode).
hypothesis: this is neither a processor nor a platform issue, but a compiler issue - i wonder if we installed gcc4.4 on ubuntu if it would compile effortlessly, and maybe even work?
if this is the case, the next step would be to track down what has changed between 4.4 and future versions, and why it works in the old world but not the new one.