On 20 September 2016 at 22:15, Hartley Sweeten <
biggu...@gmail.com> wrote:
> On Tue, Sep 20, 2016 at 9:19 PM, Henner Zeller <
h.ze...@acm.org> wrote:
>>
>> On 20 September 2016 at 10:24, Hartley Sweeten wrote:
>> > On Tuesday, September 20, 2016 10:18 AM, Hartley Sweeten wrote:
>> >> On Tuesday, September 20, 2016 9:56 AM, Hartley Sweeten wrote:
>> >>
>> >>The bone-debian-7.11-lxde-4gb-armhf-2016-06-16-4gb.img doesn't work.
>> >
>> > Update. -std-c++0x does compile and machine-control seems to work fine.
>>
>> Alright, so I updated the Makefile to use this C++ standard name. The
>> newer compilers also understand this earlier working name of the
>> standard, so this seems to be fine. Looks like because Debian 7.11 is
>> a 'long term support' version, that they still have the ancient
>> compiler.
>
>
> Sounds good. I think having BeagleG work on the long term support image
> is a good idea.
>
> One thing I forgot to check is if there is also a gcc 4.7 (or later) package
> also
> available in that image. I'll check tomorrow. If there is we could just note
> it
> in BeagleG and require that compiler (with -std-c++11).
>
> Are there any limitations with -std-c++0x vs. -std-c++11?
There are several features in the c++11 standard and the earlier
compiler versions might not have implemented all of them. The main
reason why things were called 0x then was, because it was not clear
yet what the final version would be named (and they apparently
expected it to be in the 0x years, but it became 1x).
So there might not all features be fully implemented yet, though the
bulk of the interesting features are.
Here is an overview
https://gcc.gnu.org/projects/cxx-status.html#cxx11
The bulk of the features (some quite interesting ones, such as 'auto'
and range-for loops) seemed to have been there since 4.4 already.
Some features, such as delegating constructors, we have to avoid for
now, but that is not a big deal.
It is a bit unfortunate that it seems that the 'override' keyword only
appears in 4.7 it seems. It is a great way to explicitly tell the
compiler that a particular method with a particular signature is meant
to be overriding some base class. This is great when there are changes
in the gcode parser callbacks for instance.
> Regardless, I
> guess
> we can only use the features that work with the 4.6 compiler in wheezy if
> it's
> the only one available.
Yep
>
>>
>> (The image I have on my Beaglebeone is a Debian GNU/Linux 8 (jessie)
>> and it comes with a gcc 4..9.2)
>
>
> I was trying to switch my system to the jessie image but ran into a
> problem....
>
> My cape uses one of the HDMI audio pins (P9_25 I think). I also need the
> HDMI
> video and eMMC, so unfortunately I can't move that signal because I'm using
> all
> the other non-HDMI/eMMC pins already.
>
> With the wheezy images this isn't a problem. The "HDMIN" overlay gets the
> video
> and eMMC working and the cape-universal overlay gives me all the other
> signals
> that I need for my cape.
>
> The latest jessie images appear to work a bit differently. The HDMI and eMMC
> support is loaded in the initial dtb when the system boots. It then loads
> the appropriate
> cape-universal overlay to allow access to the remaining pins. According to
> Robert
> Nelson the "HDMIN" equivalent from wheezy is not currently available in
> jessie. I
> guess he had some problems with the eMMC support. Hopefully he works it out
> at
> some point.
mmh, hopefully this is not too big of a problem. It sounds like a
problem that might be fixed soon in the jessie image.
>
> Since I'm using the cape-universal overlay for my VGEN5 hardware, I would
> prefer
> to use the jessie image since it gets everything pretty much ready during
> the boot.
> Oh well...
>
> Regards,
> Hartley