[elliotwoods]

Also for refence, here’ a link to the matching forum post over at openFrameworks:

Cross compiling for Raspberry Pi from Windows – arm – openFrameworks

[elliotwoods]

Thank you .

I was able to get PCH working with simple projects (e.g. as per the tutorial you linked), but so far not with more complicated projects.

 

Since:

1. The error message is pretty empty (as seen in my previous message)
2. There are no obvious causes
3. I’ve tried a few different approaches (e.g. only having once cpp file ‘using’ the PCH. Tried different folder layouts) and still see failures

I think the next step would be to step-by-step increasingly add all my complications to a bare project until the PCH fails. I don’t have time for that right now, but I’ll be sure to update here if I find something.

Thank you

elliot

[elliotwoods]

Still having trouble with pre-compiled headers, even when both pch.cpp and test.cpp are in the same folder as the Project file

 

`

test.cpp

Failed to compile test.cpp. arm-linux-gnueabihf-g++.exe exited with code 1

========== Project Build Summary ==========
LaserClientGDB built in 00:03
========== Build: 0 Succeeded, 1 Failed, 0 Skipped ==========

`

[elliotwoods]

Had a lot of trouble with precompiled headers, e.g.:

 

1. The precompiled header needs to be an absolute path in the project settings
2. If the path for the precompiled header is anything other than adjacent to the project file itself, then it doesn’t seem to work

[elliotwoods]

Now the emptyExample works at https://github.com/elliotwoods/ofxVisualGDBCrossCompile

[elliotwoods]

These relative paths seem to work from inside the .props file.

All source files are building now.

Working on the libs.

App builds, now we want to try and see it running…

 

[elliotwoods]

Ah there does seem to be some kind of layout to this:

 

=/usr/include/cairo

 

[elliotwoods]

There seems to be some auto-path adder?

For some reason the props file didnt’ work for the emptyExample app – but then this pop up came along

 

[elliotwoods]

I couldn’t get the Makefile system working. I tried:

1. Importing the project
2. Using the ‘make’ command that comes with the VisualGDB toolchain against the Makefile in the oF emptyExample app

Instead, I’m trying now using MSBuild (which means setting everything up from scratch).

First step is to get openFrameworks to build. I noticed that adding paths like /usr/include/gstreamer-1.0 to the include path doesn’t have any effect (includes don’t search the system paths?), you need to use the absolute path of the copy on your own computer, e.g. C:\dev\VisualGDB\rapsberrypi-buster\arm-linux-gnueabihf\sysroot\usr\include\gstreamer-1.0

 

[elliotwoods]

Success!

That was easy once I’d noticed that the toolchain was for Bullseye. I hope this is easy to find for others who hit the same issue.

• This reply was modified 2 years, 7 months ago by elliotwoods.

[elliotwoods]

Ah ok – the default Raspberry Pi toolchain is for Bullseye. I didn’t notice that.

Downloading correct toolchain now (selecting the ‘Show old pacakges’ option in toolchains)..

• This reply was modified 2 years, 7 months ago by elliotwoods.

[elliotwoods]

The only other toolchain available with VisualGDB seems to be the 64bit version, and I’m not running in 64bit Raspbian (e.g. uname -m returns armv7l).

 

[Author]

Posts