-
Notifications
You must be signed in to change notification settings - Fork 36
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Error building on Raspberry Pi 2 #254
Comments
1st, show the compiler version.
2nd, try another. Stable GCC is always a good choice.
|
So it's 4.9.2. Also, this is what's on default Raspbian (Raspberry Pi GNU/Linux official distro) right now, nothing unstable/experimental... More info about the compiler:
|
yep, quite old.
Do you have any other gcc version available? Try.
|
@ildar : This is what we have on Raspbian. I could of course build my own gcc 5.x but even if that works, it won't be using Raspbian's compiler... |
I remember we had that problem before. Is it possible that the build system take too much memory on the compiling system. What if you try to build it again. |
@gerstrong |
Distros usually have more then one compiler available. I suggest you seek
for that and try one of those
|
@Lidar: Do you mean other than GCC or a different GCC version? |
Any.
Preferably another gcc
|
I need to check that serializer. I find it strange that it does not happen here even with the same gcc as you use. |
@gerstrong: Do you mean you're also building for ARM or do you mean the same gcc building for X86? |
At the very least Android port is available
|
Actually we use the Android NDK for compiling Commander Genius. We had a lot of alignment problems and so on, but pelya really helped on that. Since then all the architectures are supported including ARM. |
@gerstrong : I still don't get it. Are you building for X86 or ARM? (with the same compiler I am using) |
Both and and also MIPS, but the Android NDK provides these compiler and they are executed all together when the APK is built |
@gerstrong What does that "serializer" do? Can it be modified somehow to avoid the error? Is it needed for the main games or is it dependant on some accesory functionality that could be disabled at configure time? |
It collects all the game data required for a save state. If you disable that class you are going to loose the save game feature. That would not help at all, we need to find out, why it complains. Did you try another compiler. It seems to me an unstable version. Or is C++11 somehow disabled? |
@gerstrong: C++ 11 is enabled specifically. This is a compilation line (used make VERBOSE=1 to get the complete compilation lines displayed):
The compiler is "stable": it's the one in the official Raspberry Pi tools. Nothing custom, it's Raspbian's current version. |
@gerstrong : got it to build by lowering the optimization level in src/CMakelists.txt from O3 to O2. |
Hey cool. Why it crashes with Video I cannot tell. Hmm. How could I reproduce that? |
Could you run under gdb to get the backtrace or/and coredump?
Anyway IMHO you need to try other compilers.
|
Hi I have found major issues with the sound threads and fixed those. Could you retry building CG and let me if it works better now? |
I am getting some undefined references on linking:
I am configuring like this:
|
Try to compile one of the tag version. I'm still fixing dreams code for Am 25.07.2016 um 13:41 schrieb The Last Cabra:
|
With the last tag version (v1953beta) I get the same problems on linking:
` Building a previous version I wouldn't get your audio thread fixes. |
Try the last upload. It should be better now... |
I have got to build this on the Pi3 finally, with some caveats... I had to change every O3 to O2 in the build files. Then I have configured with: cmake -DUSE_SDL2=ON -DBUILD_TARGET=LINUX -DCMAKE_BUILD_TYPE=Release -DDBFUSION=OFF -DTREMOR=OFF -DOPENGL=OFF -DDOWNLOADER=OFF .. It builds, but the resulting executable graphics are ugly as sin, because the vsync and bilinear interpolation are ignored. Luckily, SDL2 on the Pi uses a GLES renderer ALWAYS, which is a very good thing as the interpolation is done on the renderer side if the correct SDL_SetHint() is added.
before SDL_CreateRenderer(). So, in my opinion: Also, having vsync ON properly (by adding the SDL_RENDERER_PRESENTVSYNC flag to SDL_CreateRenderer()), the game's loop should NOT be waiting on anything: speed MUST rely on vsync. Framerate is limited by vsync and that's all that should happen. Right now, the timming with VSYNC on is broken, as the game sometimes goes down from 60FPS to 30FPS because it's unable to keep up with the physical screen refresh because of the added delays, which should go away when VSYNC is on. |
hi @vanfanel
SDL 1.2 is still used for some older devices and Android for that one we use the additional OpenGL code. Sorry for responding a bit late. I have a bit time now will try to fix some issues. Anyways thanks for the hints. About the gameloop: I'm happy how it is implemented. I'll take another look. The logics per second is fixed so the game feels the same on every systems. About graphics I'll take a look. |
Closing this because it seems I don't read any more complains |
I am trying to build on Pi2, but I get this:
I configured CG with these:
cmake -DUSE_SDL2=yes -DBUILD_TARGET=LINUX -DCMAKE_BUILD_TYPE=Release -DDBFUSION=no -DTREMOR=NO -DOPENGL=no -DREFKEEN=no ..
Any idea on what is going on here?
The text was updated successfully, but these errors were encountered: