Noob Question: OpenFL compiles a shared library when targeting Linux?

Hey all. So I started trying to develop with Haxe and OpenFL the other day and I’m completely new at it. I worked through this tutorial (with some modifications since I don’t have the FlashDevelop IDE) and was able to build the game, targeting both HTML5 and Neko. I can build targeting Linux as well, but the weird thing is the output file is a shared library and not a standard executable. This happens when I build using the openfl command from the project folder:

openfl build linux

In any case, I can run the game from the terminal, but when I try to run it from the Xfce file manager it won’t open, and I suspect it is because the file manager sees it as a library and not an actual program. It’s fine for testing the program, and I don’t plan on distributing the game from the tutorial. But if I were going to distribute a program I’d want the end user to be able to run it without the terminal or writing a shell script to do it.

I’m guessing there is something terribly simple that I’m just missing. Any help is appreciated!

OpenFL creates a binary executable for Linux, based on the <app file="" /> name. There are some shared library dependencies (like “lime.so”), but that’s not the application.

If it does not work from the file manager, perhaps it has something to do with the current working directly when it is launched.

I have had difficulty coming up with a solution that allows us to know the location of our executable at runtime (in order to resolve references such as the shared libraries or asset files), perhaps there is a way we could improve this?

Thanks for the reply, singmajesty.

This may actually be a window manager issue and perhaps this isn’t the place to resolve it. When I “ls -l” the folder it shows the file as executable, and it does indeed execute from a shell. But when I double-click the file in the file manager, nothing happens. In the description in the bottom corner, it calls it a “shared library”.

For whatever reason, the window manager doesn’t “see” the file as executable. I don’t know a great deal about the file structure of Linux executables, but I thought perhaps there was some flag the compiler was supposed to set to make it appear as an executable. If that was the case it would be an OpenFL or Haxe issue, since if it exists that flag isn’t being set.

I have not had this issue compiling C++ programs using g++ in the past.

Hopefully that clarifies the problem.

I think it might have something to do with -fPIC

Does it work if you comment or remove these flags from the “linux-toolchain.xml” file in your HXCPP install?

(Keep -fpic and -fPIC under the “dll” section, but remove from the “exe” section as linked)

Thanks :slight_smile:

No, it didn’t work.

It makes sense that it would be some compiler option though, I just couldn’t tell you which one. I spent some time looking through the GCC documentation and didn’t immediately find an explanation. It seems like it would have something to do with the use of the “-c” option:

<flag value="-c"/>

But, when I comment that out it fails to compile entirely. The output is quite a bit more extensive than I’d want to put in this post, but there is a lot of “undefined reference to ‘hx::(something)’:”.

I’ve done quite a bit of searching and trying different things, basically throwing at the wall and seeing what sticks.

I thought maybe “-static” would be the magic word? But when I try to build that way I get “g++: error: /usr/share/haxelib/lime/3,4,1/ndll/Linux64/liblime.a: No such file or directory”.

So theres a library missing that I just can’t seem to find. So my question is twofold:

Does this actually have anything to do with what I’m trying to do?

How do I go about obtaining/creating the missing file?

Follow the directions on https://github.com/openfl/lime for a development version of Lime, then I think you’ll need:

lime rebuild hxcpp linux -static
lime rebuild linux -static
lime test linux -static

Static does disable audio, though, since OpenAL is GPL, but it’s worth a shot to see if it affects how XFCE treats the application.

Tried it with the development build following your instructions. Same error: “liblime.a” isn’t there.

I also tried the regular build on KDE, and it has the same problem as Xfce, file manager sees a shared library and not an executable. So I don’t think it’s a window manager problem.

You can always confirm file type using file command.

Whats the actual problem there? Isn’t lime.system.System.applicationDirectory working correctly?