"create extension" fails with error

Tried following on mac:

$ openfl create extension TestExtension
Error: Could not find sample “extension” in project “openfl”

At the same time:
$ lime create extension test2

seems to work. What am I doing wrong?

Not sure if it’s a good idea to ask in the same topic, but I also failed to find examples of adding native libraries (I need google protobuf for cpp/linux target) and I also want to have a static build for my final project. It seems possible, but may be there are better ways to achieve it besides extensions…?

If you need your own C++ code, I’d recommend an extension. Currently extensions are not designed to be linked statically, though. This could be done for sure (there’s nothing technical that prevents it) but the tools are not set up currently to expect it and link differently for it.

openfl create extension not working must be a bug, lime create extension is fine, and does the same thing. That should give an example for compiling a standalone C++ binary that’s available for projects to use. lime rebuild <path to extension or haxelib name> linux should recompile the extension, then <include path="to/extension" /> or <haxelib name="of-extension-if-its-a-haxelib" /> will include both the code and C++ library from your extension in a project

Thank you very much for such a clear explantation. Now at least I can try it:) I guess I’ll have a lot of fun trying to link with external libraries (for google protobuf for example). Can you give me some directions / example projects / documentation to look at before?

I did it:) by just putting all my code into extension:) still I’ll appreciate any hints on how to statically link extension into the final project.

I think you could lime rebuild <name or path of extension> windows -static to build a static (instead of a dynamic) version

Next, the key would be linking this when building. You probably would need to do a static build of your application. For Lime 2 (which OpenFL -Dnext uses) I confirmed static build support for Windows, Mac and Linux. I think this might actually work out of the box.

I have not tried compiling the Lime 1 legacy binaries (which OpenFL native uses by default, currently) as a static build, but it can’t be (too?) complicated. Would be happy to help if someone is interested in taking a look

While playing with various ways of building on linux, I’ve found that:

openfl build linux -Dnext -Dstatic

still leaves lime.ndll as a runtime dep, the only way of building that seems to try to link lime staticaly is:

openfl build linux -Dnext -Dstatic -Dstatic_link

but it fails on the file stage:

ar -cr ApplicationMain.a @obj/linux-stat//all_objs
ranlib ApplicationMain.a
Error: Source path "Export/linux/cpp/obj/ApplicationMain" does not exist

while I attempt to build final binary with:

g++ -o /tmp/App @obj/linux-stat/all_objs -lpthread -ldl  .../../../sources/lime/ndll/Linux/liblime.a

seems to be working:

RunLibs.cpp:(.text+0x15): undefined reference to `std_register_prims'
RunLibs.cpp:(.text+0x1a): undefined reference to `regexp_register_prims'
RunLibs.cpp:(.text+0x1f): undefined reference to `zlib_register_prims'

which are the errors for each *.dso files in final dynamic build. My guess is these *.dso could also be built as *.a files on linux, but I’m lost… how to to build these? somehting related to rebuilding hxcpp maybe?

Try -static, not -Dstatic

Hmm… Some progress here:

$ openfl build linux -static -Dnext
...sources/lime/ndll/Linux/liblime.a(5c4c0827_inflate.o): In function `inflateReset':
inflate.c:(.text+0x280): multiple definition of `inflateReset'
/usr/lib/haxe/lib/hxcpp/3,1,68/lib/Linux/libzlib.a(69ebc970_inflate.o):inflate.c:(.text+0x220): first defined here
/home/ds/sources/lime/ndll/Linux/liblime.a(5c4c0827_inflate.o): In function `inflateInit2_':
.... # output for various zlib functions

attempt to exclude libzlib.a and run linking manually:

$ g++ -o Main -rdynamic -m32 @obj/linux-stat//all_objs /usr/lib/haxe/lib/hxcpp/3,1,68/lib/Linux/libstd.a /usr/lib/haxe/lib/hxcpp/3,1,68/lib/Linux/libregexp.a .../../../sources/lime/ndll/Linux/liblime.a /usr/lib/haxe/lib/hxcpp/3,1,68/lib/Linux/liblinuxcompat.a -lpthread -lrt ApplicationMain.a -ldl
obj/linux-stat/3c79f9bd_Main.o: In function `main':
Main.cpp:(.text.startup+0x25): undefined reference to `zlib_register_prims'
ApplicationMain.a(f2885469_RunLibs.o): In function `hxRunLibrary':
RunLibs.cpp:(.text+0x1f): undefined reference to `zlib_register_prims'
collect2: error: ld returned 1 exit status

am I still missing something?

Yep, this looks like forward progress :smile:

HXCPP includes zlib, because some of the Haxe standard methods use zip compression. However, Lime also includes zlib. As a result, we need to include only one or the other, not both. I think I may have resolved this problem for iOS (which is always a statically-linked build), see:

Perhaps this could be if="ios || static" or if="ios || static_link" (see if one of those works), there might probably be another place that includes the “zlib” NDLL (maybe “include.xml”), where we would want to exclude the HXCPP version, since we’re compiling it into the Lime static lib instead

But this is for “legacy” not -Dnext? I used to think I should try -Dnext? Or is it not really important?

before your reply I’ve tried changing to “linux” here https://github.com/openfl/lime/blob/master/project/Build.xml#L158 without any success.

Yeah, try that, but you might also need to modify this one:

Did that already:)) now trying to find out where did this came from:

openfl build linux -static -Dnext
ApplicationMain.a(f2885469_RunLibs.o): In function `hxRunLibrary':
RunLibs.cpp:(.text+0x1f): undefined reference to `zlib_register_prims'
collect2: error: ld returned 1 exit status

Looks I’m almost there anyway thanks to your help:)

Did you catch the BuildMain.xml and Main.cpp templates, with the added reference to zlib_register_prims like emscripten?

Try adding something similar to this one:

Yes, I’ve added libzlib.a to BuildMain.xml like this:

<lib name="${HXCPP}/lib/${BINDIR}/libzlib.a" />

and I can see modified linking command:

g++ -o Main -rdynamic -m32 @obj/linux-stat/all_objs /usr/lib/haxe/lib/hxcpp/3,1,68/lib/Linux/libstd.a /usr/lib/haxe/lib/hxcpp/3,1,68/lib/Linux/libregexp.a /home/ds/sources/lime/ndll/Linux/liblime.a /usr/lib/haxe/lib/hxcpp/3,1,68/lib/Linux/libzlib.a /usr/lib/haxe/lib/hxcpp/3,1,68/lib/Linux/liblinuxcompat.a -lpthread -lrt ApplicationMain.a -ldl

but problem still here:

ApplicationMain.a(f2885469_RunLibs.o): In function `hxRunLibrary':
RunLibs.cpp:(.text+0x1f): undefined reference to `zlib_register_prims'
collect2: error: ld returned 1 exit status

looks like there are more places to modify… :frowning:

But it’s very strange, I’ve checked with

nm libzlib.a

and it shows zlib_register_prims is there…

Hmm, well the idea (normally) is that instead of including libzlib.a, we manually compile in the file that has zlib_register_prims along with our own zlib version. Lime uses a newer zlib than HXCPP, so this allows everything to use the one, newer version of zlib.

Perhaps a -clean build would help?