Unresolved symbols for emscripten target about lime

[DavisDevelopment]

I honestly don't know nearly enough about C++ to attempt to solve this problem. :/ I really would love be able to deploy to JS via Emscripten, since that would be many times faster than Haxe's standard HTML5 target, but so far, I've had little luck. Perhaps we could hit up the guy that wrote Emscripten, and request his help? I think that he would certainly be able to tell us what's going on, but I'd imagine that he's quite busy as well. Maybe we could put our heads together and try to figure this one out on our own? I'm at a loss alone.

[jgranick]

Hey guys,

Emscripten was defined for statically linking the libraries. "lime", "std", "regexp" and "zlib" are ordinarily external dependencies, but for Emscripten, they're linked together.

The first step is to ensure that a "lime" library exists in the "lime/ndll/Emscripten" directory (by calling "lime rebuild emscripten") and "std", "regexp" and "zlib" libraries exist under "hxlibc/ndll/Emscripten" (by calling "lime rebuild hxlibc emscripten").

When statically linking, the application has "_register_prims" method calls in order to ensure that the symbols to the target library are brought in, and early. If you have these separate libraries built, then there could be a problem in the linking

[tptee]

Ran these commands, all the libraries are there, still the same errors.

This warning might be relevant:

WARNING root: -I or -L of an absolute path "-I/usr/lib/haxe/lib/hxlibc/1,1,2/include" encountered. If this is to a local system header/library, it may cause problems (local system files make sense for compiling natively on your system, but not necessarily to JavaScript). Pass '-Wno-warn-absolute-paths' to emcc to hide this warning.

Thanks for looking into this!

On Dec 26, 2013, at 2:50 PM, Joshua Granick [email protected] wrote:

Hey guys,

Emscripten was defined for statically linking the libraries. "lime", "std", "regexp" and "zlib" are ordinarily external dependencies, but for Emscripten, they're linked together.

The first step is to ensure that a "lime" library exists in the "lime/ndll/Emscripten" directory (by calling "lime rebuild emscripten") and "std", "regexp" and "zlib" libraries exist under "hxlibc/ndll/Emscripten" (by calling "lime rebuild hxlibc emscripten").

When statically linking, the application has "registerprims" method calls in order to ensure that the symbols to the target library are brought in, and early. If you have these separate libraries built, then there could be a problem in the linking

—
Reply to this email directly or view it on GitHub.

[DavisDevelopment]

Thanks for the help, Joshua. I'll try what you suggested, and see what I get. Hopefully it helps :)

[jgranick]

I tried installing the latest version of Emscripten today, and giving everything a try. With some work, I've got it all compiling, linking together and running. For some reason, though, the rendering is wrong.

Drawing a square using an OpenGLView, the GL.clear call appears properly, but the square will only appear every 30 or so seconds for a flicker. Trying a sample such as PiratePig, may appear white on one browser, or like it intermittently works on another. I'm not really sure what's going on -- it seems to be entirely rendering related, since under the hood trace messages and logic appears to be rolling again just properly.

I'm not sure if this is due to the latest version of Emscripten, and a bug, or perhaps some minor regression on our part, which doesn't affect GL, GLES or WebGL targets, only Emscripten :/

[jgranick]

On the other hand, it seems to advanced quite a bit (problems I had before are gone) and seems to build much faster, or maybe its just this computer? It would be exciting if this were viable

[jgranick]

If you want to test the latest, you will need development versions of hxlibc, lime, lime-tools and openfl-native. Sorry it touches so many places, we dropped official Emscripten support before OpenFL 1.1, so there's been some catching up to get it running properly

[tptee]

All very cool, looking forward to trying this with the dev versions. I can't even imagine the complexity behind openfl -> c++ -> js :)

On Dec 26, 2013, at 11:07 PM, Joshua Granick [email protected] wrote:

If you want to test the latest, you will need development versions of hxlibc, lime, lime-tools and openfl-native. Sorry it touches so many places, we dropped official Emscripten support before OpenFL 1.1, so there's been some catching up to get it running properly

—
Reply to this email directly or view it on GitHub.

[jgranick]

Actually, it may be more of a Firefox issue ATM. Chrome appears to be displaying simple samples, though (for some reason) it does not animate properly yet

[jgranick]

After some research, something about Emscripten appears to not like the behavior of Actuate. If I take a simple object and tween along one property, it works fine. If I try tweening along two, it doesn't work right, or crashes out. This works on every other target, it must be something with an Emscripten optimization? Something with dynamic access, I guess

[DavisDevelopment]

There's a workaround for that, actually, and in my opinion, the design pattern that it enforces is more efficient anyway. What you do is create a main class that all your game objects inherit from, and in your main class, create an array, which stores all of your game objects. When you add an object to your stage, also add it to that array. Instead of using Actuate to animate, create an update method for your main class, and in that method, loop through all elements in the array, and call their update methods. That way, the logic for animating your objects is encapsulated within their classes, and Actuate isn't doing it. I'm actually working on what I call the Gryffin Engine, which allows you to create a Stage object, and all game objects are stored there. Every game object has a render method, and a update method, so all the logic for rendering/updating them in stored in their classes. The Stage object also has a get method, which takes a selector string as it's argument, the engine runs that string through it's built-in selector-string parser, generating a selector function of type GryfObject -> Bool, and returns an array of all game objects for which that function returned true. All update and render methods take two arguments: the first is a flash.display.Graphics object, and the other is the Stage object itself. So, using selector strings, you can access any other game object on the stage, from within any other object's class. Both the Stage and GryfObject fully support Event binding, so you're not limited there. As an added bonus, the engine also has it's own built-in scripting language, which can be used to script game objects, or modify the behavior of pre-existing objects. The language is almost identical to JS, with the exception of it's module system, and support for classes. All this is completely implemented in Haxe, so it's completely cross-platform. I created this to allow a better MVC system than was present in pure-vanilla OpenFL. Using this engine, or a similar system of your own, you can work around the problems Joshua mentioned. I may be releasing early versions of the engine to Github for open-source use, but the engine is largely closed-source, that's why I explained the way it works, rather than releasing it. Sorry for posting a novel :)

[jgranick]

Hey guys,

Great news! I tracked back 1503 commits back to find where Emscripten broke. They made a different frontend for LLVM the default, which triggered some of these data type issues. I have gotten things running again using the latest version of Emscripten, the updates are propagated across each library, and the next release should have official Emscripten support again. It does not mean that we will be able to track down every bug that may occur with Emscripten, but it should enable "lime test emscripten" out-of-the-box.

[tptee]

Awesome, thanks for all the hard work! Can't wait to try this out!

On Dec 27, 2013, at 8:35 PM, Joshua Granick [email protected] wrote:

Hey guys,

Great news! I tracked back 1503 commits back to find where Emscripten broke. They made a different frontend for LLVM the default, which triggered some of these data type issues. I have gotten things running again using the latest version of Emscripten, the updates are propagated across each library, and the next release should have official Emscripten support again. It does not mean that we will be able to track down every bug that may occur with Emscripten, but it should enable "lime test emscripten" out-of-the-box.

—
Reply to this email directly or view it on GitHub.

[jgranick]

You may have caught this already, but the next release of OpenFL and Lime went out, with Emscripten support again :)

[DavisDevelopment]

And this support works properly? :D I would be so happy to see this working, because deploying to JS is the best way to debug a program for me, since I started my programming career as a JavaScript developer, and am most accustomed to that language. The problem with this is that my game's engine won't work properly on the HTML5 target. GryffinScript evaluates properly, but the rendering is extremely off. This is seemingly caused by something with the engine's tile system, because if I make an app that doesn't use the tile system, it works fine.

[tptee]

Hey guys, tried building with Emscripten using updated versions of lime, lime-tools, lime-build, hxlibc, and OpenFL. Everything worked for a trivial test (single class running trace() and nothing else), but with a larger app, I run into new unresolved symbols:

I'm guessing FT is the prefix for libfreetype, and it looks like the issue might lie there. Tried every rebuild command I could think of to no avail. Any ideas?