Did you already try to cross-compile a Juce application for ARM-Linux?
:?: Ok, why do I need that? I’m currently porting CopperLan to RaspberryPi. I’m not so used with the Linux command line dev tools, so I re-used the existing Eclipse project we made previously for other custom platforms running Embedded Linux. My current status: I am able to build my stuff (deamon & console tools) under Windows using Eclipse/Cygwin/Toolchain provided here, and it’s running perfectly on the Raspi.
But now I would like to build a test applications based on Juce… a very simple “Hello world”. I’ve configured an Eclipse project from the make file provided by Introjucer, it is compiling the application source code, but I get this error on the first Juce source code file:
Compiling juce_core.cpp
In file included from ../../JuceLibraryCode/modules/juce_core/juce_core.cpp:40:0:
../../JuceLibraryCode/modules/juce_core/native/juce_BasicNativeHeaders.h:168:25: fatal error: sys/ptrace.h: No such file or directory
compilation terminated.
make: *** [build/intermediate/Debug/juce_core_aff681cc.o] Error 1
I thought it was just a missing include path, but I have searched for this ptrace.h file under Cygwin & toolchain without success…
My test application is very basic (just a simple “hello world” window), just using juce_core, juce_data_structures, juce_event, juce_graphics, juce_gui_basics, juce_gui_extra, and juce_opengl modules. Same result for debug and release configs.
Well, presumably it doesn’t support ptrace - but that’s not a disaster, because juce only uses it for one non-essential function. You could try just hacking it out and seeing if you get any further.
Forget it, it’s an Eclipse configuration issue. My fault, I just missed the fact that I have to declare include path in Introjucer instead of Eclipse project settings… :roll:
However I still have other issues (such as “…ctype_base.h:44:35: error: ‘_U’ was not declared in this scope”) but I guess it’s related to the cross-compiler config, I certainly need to add some flags. So I continue searching how to make it running, then I’ll post the solution here. I’m pretty sure I’m not the only guy wanting to cross-compile Juce app for Raspi
now I have this error:
…/…/JuceLibraryCode/modules/juce_core/text/juce_String.cpp:217:9: error: incomplete type ‘juce::JuceStaticAssert’ used in nested name specifier
and later:
…/…/JuceLibraryCode/modules/juce_core/native/juce_posix_SharedCode.h:239:56: error: invalid use of incomplete type ‘struct juce::::stat64’
…/…/JuceLibraryCode/modules/juce_core/native/juce_posix_SharedCode.h:229:20: error: forward declaration of ‘struct juce::::stat64’
I’ve searched about this “stat64” structure… not found in the toolchain.
I’ve also this; even pthread.h is well included (no error on #include):
…/…/JuceLibraryCode/modules/juce_core/native/juce_posix_SharedCode.h:40:43: error: ‘PTHREAD_PRIO_INHERIT’ was not declared in this scope
and also:
…/…/JuceLibraryCode/modules/juce_core/native/juce_posix_SharedCode.h:586:13: error: ‘Dl_info’ was not declared in this scope
About Cygwin, I’m no sure why it is needed… but if you google on “raspberry cross compile”, the few solutions proposed always refer to cygwin…
Finally it seems that the solution I’m using (based on Ian Lindsell toolchain) is not the right one to cross-compile Juce apps…
if anyone here can offer an alternative, please let me know :!:
And if you want to stay on your main mouse, keyboard and monitor, do it via SSH. On *nix platforms, you can forward the X protocol and use a GUI over SSH too. That works a treat.
yes but… I’m not used with Linux tools/environment. I’m very slow and unefficient on this platform… and the projects I’m working on are huge. So I prefer to maintain the source code in my laptop, using the dev and repository tools I know (Mac or Windows). I do that with other embedded platforms (Pic32/AVR). For me the Raspi is just another embedded platform, and I’m trying to avoid spending time to learn an environment I’ll use only occasionally…
That’s a great goal - I’m with you there… but it’s not am embedded target, with an provided fixed toolset, by any means; it’s a computer, and I think the assumption is that you’ll work right on it.
An off the shelf Eclipse or CodeBlocks installation with RaspPi support is your best bet then. If you put GDB onto the box, you should be able to do remote debugging.
Actually, I’m considering the Raspi as an embedded system because we have been working on other custom boards running Embedded Linux but having no keyboard nor screen, mainboards for complex equipment. These boards were programmed using cross compiler and remote debugging. I’m just trying to do the same with the Raspi, and I miss the right toolchain (usually provided by our customers)
So yes, the Raspi is technically a computer, but practically it’s not powerfull enough to support heavy project building… so for me it’s an embedded board in my opinion the limit between embedded and computer world is moving depending on the context.
Well, I’ll continue investigating. I’ll keep you informed if I find out something usable.
in my opinion the limit between embedded and computer world is moving depending on the context.