Statically-linked application crashes during run-time

#1

Hey there!

To publish my game I linked all the libraries statically by building from lime-source. The game starts perfectly on my machine and on different systems.

However, when entering a level the game crashed on all systems without a clear error message - just the standard “Application hast stopped working”-error.
Strangely the crash could neither be reproduced in Neko or an unlinked C+±Target nor would any exception be displayed while running those.

Do you have any idea which reason such an error could have? Could it have something to do with OpenGl or loading resources?

Thanks in advance!

Edit

After continuous testing I could reduce the error-source to playing audio-files (ogg to be ecactly). After commenting those out, the application ran perfectly.

Why does this happen? Are there special ogg-Libraries, that have to be included aswell? I would really appreciate someone giving me a clue.

#2

Oh! Okay. I know the reason :smile:

We use OpenAL on standard builds, but not static builds. OpenAL (sadly) is GPL-licensed, TL;DR it means that all your game’s source code would have to be provided open-source if someone asked. We thought that was a bad idea, so for the moment, we don’t include OpenAL for static builds so this does not happen by mistake.

I’m not sure what the best solution is, but I’m all ears. :slight_smile:

1 Like
#3

Thanks for the answer. Really makes sense now.

But you have to light me up on two questions:

  1. There are plenty of examples of commerical games using OpenFL as their framework of choice. How would they publish a game to run on client’s machines?

  2. Actually my game is open source, as its an educational project. How can one include OpenAL when building for the “-static” target?

Thank you :+1:

#4

Ad1. They build probably with shared version of line.ndll and add it to the app bundle.
Parts of OpenAL, SDL2 and other libs are in the lime.ndll (which is itself opensource and dynamicaly linked) I think.

#5

If you want to include OpenAL anyway, try -Dlime-openal when building your project. I need to look more at allowing easier enabling/disabling of this

#6

Alright, so the proper setup for including OpenAL at the moment, I believe, is the following:

lime rebuild windows -static -DLIME_OPENAL
lime test windows -static -Dlime-openal

We may need to make minor adjustments to the Lime Build.xml if the above does not work, I have not tested it yet. If you think there’s an even nicer way to handle this, I’m interested as well :smile:

Thanks!

#7

Maybe we could use OpenSL ES?

#8

I think OpenSL ES is only embedded on devices, Android (for example) supports OpenSL ES, so we have an OpenAL version that uses it as a backend