"create extension" fails with error

dimsam · February 26, 2015, 3:39am

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…?

singmajesty · February 26, 2015, 4:20pm

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

dimsam · February 26, 2015, 7:40pm

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?

dimsam · February 27, 2015, 4:32am

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.

singmajesty · February 27, 2015, 11:36pm

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

dimsam · March 4, 2015, 9:26pm

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?

singmajesty · March 4, 2015, 11:20pm

Try -static, not -Dstatic

dimsam · March 5, 2015, 12:58am

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?

singmajesty · March 5, 2015, 2:16am

Yep, this looks like forward progress

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:

github.com

openfl/lime/blob/e511c0d2a5d616081a7826416d111aff1d428025/legacy/project/Build.xml#L258


		<!-- You will need this if you want USE_POLY2TRI in Tesselate.cpp
		<file name="${LEGACY_SRC_DIR}/common/poly2tri/Poly2Tri.cpp" />
		-->
		
		<file name="${LEGACY_SRC_DIR}/lzma/LzFind.c" />
		<file name="${LEGACY_SRC_DIR}/lzma/LzmaDec.c" />
		<file name="${LEGACY_SRC_DIR}/lzma/LzmaEnc.c" />
		<file name="${LEGACY_SRC_DIR}/lzma/LzFindMt.c" if="windows" />
		<file name="${LEGACY_SRC_DIR}/lzma/Threads.c" if="windows" />
		
		<file name="${HXCPP}/project/libs/zlib/ZLib.cpp" if="ios" />
		
	</files>
	
	<set name="LEGACY_SLIBEXT" value=".lib" if="windows" />
	<set name="LEGACY_SLIBEXT" value=".a" unless="windows" />
	<set name="LEGACY_PRELIB" value="${LEGACY_DEV}/lib/${BINDIR}/lib" />
	<set name="LEGACY_POSTLIB" value="${LIBEXTRA}${LEGACY_SLIBEXT}" />
	<set name="LEGACY_DEBUGEXTRA" value="-debug" if="fulldebug" />
	
	<target id="lime-legacy" output="${LIBPREFIX}lime${MSVC_LIB_VERSION}${LEGACY_DEBUGEXTRA}${LIBEXTRA}" tool="linker" toolid="${STD_MODULE_LINK}">

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

dimsam · March 5, 2015, 2:33am

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.

singmajesty · March 5, 2015, 3:11am

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

github.com

openfl/lime/blob/master/include.xml#L32


	
	<haxelib name="nodejs" if="nodejs" />
	<haxelib name="format" if="java" />
	
	<target name="ps3" handler="lime-ps3" />
	<haxelib name="lime-ps3" if="ps3" />
	
	<target name="ps4" handler="lime-ps4" />
	<haxelib name="lime-ps4" if="ps4" />
	
	<target name="vita" handler="lime-vita" />
	<haxelib name="lime-vita" if="vita" />
	
	<target name="switch" handler="lime-switch" />
	<haxelib name="lime-switch" if="switch" />
	
	<target name="wiiu" handler="lime-wiiu" />
	<haxelib name="lime-wiiu" if="wiiu" />
	
	<target name="xbox1" handler="lime-xbox1" />
	<haxelib name="lime-xbox1" if="xbox1" />

dimsam · March 5, 2015, 3:13am

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:)

singmajesty · March 5, 2015, 3:16am

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

github.com

openfl/lime/blob/e511c0d2a5d616081a7826416d111aff1d428025/templates/emscripten/cpp/Main.cpp

/*
 *  Main.mm
 *
 *  Boot code for lime.
 *
 */

#include <stdio.h>

extern "C" const char *hxRunLibrary ();
extern "C" void hxcpp_set_top_of_stack ();

extern "C" int zlib_register_prims ();
extern "C" int lime_openal_register_prims ();
::foreach ndlls::::if (registerStatics)::extern "C" int ::name::_register_prims();::end::
::end::


extern "C" int main(int argc, char *argv[])	{

This file has been truncated. show original

Try adding something similar to this one:

github.com

openfl/lime/blob/e511c0d2a5d616081a7826416d111aff1d428025/templates/cpp/static/Main.cpp

#include <stdio.h>

#ifdef HX_WINDOWS
#include <windows.h>
#endif

extern "C" const char *hxRunLibrary ();
extern "C" void hxcpp_set_top_of_stack ();

::foreach ndlls::::if (registerStatics)::
extern "C" int ::name::_register_prims ();::end::::end::


#ifdef HX_WINDOWS
int __stdcall WinMain (HINSTANCE hInstance, HINSTANCE hPrevInstance, LPSTR lpCmdLine, int nCmdShow) {
#else
extern "C" int main(int argc, char *argv[]) {
#endif
	
	hxcpp_set_top_of_stack ();

This file has been truncated. show original

dimsam · March 5, 2015, 4:06am

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…

dimsam · March 5, 2015, 4:14am

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

nm libzlib.a

and it shows zlib_register_prims is there…

singmajesty · March 5, 2015, 5:04pm

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?