Building for desktop targets - missing library issues

[Michael Cook]

I'm building a game to non-flash platforms for the first time. While it runs on my two home machines (one Mac 64bit in development mode, one Windows 7 64bit using the build) just fine, it doesn't run on other people's machines. One tester running Windows 8 reported:

Uncaught Exception - load.c (237) Failed to load library: std.dll

While another running Windows 7 reported:

failed to load library std.ndll

Linux also doesn't run on Linux tester machines, and the Mac app won't run on my machine (even though all test targets run on the Mac - this is my development machine). I can only conclude I'm making some mistake in how I build. Is there anything obvious I might be missing? I used the normal lime test <platform> to build all targets.

Thanks

[Gama11]

Did you distribute the entire /bin folder? Including the std.dll?

[Michael Cook]

I do, but it's just occurred to me that the testers may not be unzipping the full folder contents... I'll chase it up. Thanks.

--
HaxeFlixel Development Community
See our github https://github.com/haxeflixel/ and our documentation http://haxeflixel.com/documentation/
---
You received this message because you are subscribed to a topic in the Google Groups "HaxeFlixel" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/haxeflixel/Dw79gwD_YHs/unsubscribe.
To unsubscribe from this group and all its topics, send an email to haxeflixel+...@googlegroups.com.
Visit this group at http://groups.google.com/group/haxeflixel.
To view this discussion on the web visit https://groups.google.com/d/msgid/haxeflixel/053728c9-1c65-4459-91c6-afccbb17408c%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--
Michael Cook

www.gamesbyangelina.org

[Michael Cook]

Hmm, testers reporting back that they did unzip the folder correctly. So it can't be that - I distributed everything. 

Mike

On Tuesday, July 22, 2014 4:41:14 PM UTC+1, Michael Cook wrote:

I do, but it's just occurred to me that the testers may not be unzipping the full folder contents... I'll chase it up. Thanks.

On 22 July 2014 16:17, Gama11 <> wrote:

Did you distribute the entire /bin folder? Including the std.dll?

On Tuesday, July 22, 2014 4:46:52 PM UTC+2, Michael Cook wrote:

I'm building a game to non-flash platforms for the first time. While it runs on my two home machines (one Mac 64bit in development mode, one Windows 7 64bit using the build) just fine, it doesn't run on other people's machines. One tester running Windows 8 reported:

Uncaught Exception - load.c (237) Failed to load library: std.dll

While another running Windows 7 reported:

failed to load library std.ndll

Linux also doesn't run on Linux tester machines, and the Mac app won't run on my machine (even though all test targets run on the Mac - this is my development machine). I can only conclude I'm making some mistake in how I build. Is there anything obvious I might be missing? I used the normal lime test <platform> to build all targets.

Thanks

--
HaxeFlixel Development Community
See our github https://github.com/haxeflixel/ and our documentation http://haxeflixel.com/documentation/
---
You received this message because you are subscribed to a topic in the Google Groups "HaxeFlixel" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/haxeflixel/Dw79gwD_YHs/unsubscribe.

To unsubscribe from this group and all its topics, send an email to .

Visit this group at http://groups.google.com/group/haxeflixel.
To view this discussion on the web visit https://groups.google.com/d/msgid/haxeflixel/053728c9-1c65-4459-91c6-afccbb17408c%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--
Michael Cook

www.gamesbyangelina.org

[Michael Cook]

I still have no solution to these issues. Can anyone talk me through a basic build-for-windows guide? I've tried the following:

+ Building my game normally

+ Building a fresh template Flixel project

+ Installing Haxe + Openfl fresh on my other machine (a windows one) and building my game on there

None of these three produced windows executables that ran on tester machines. They run on my own windows machine, and my development machine can run the code on the mac targets fine. But not hte windows builds. I'm exporting the entire folder. What's going wrong?

[Lars Doucet]

Hey there!

So depending on what libraries you're using, you might need to package some core dll's with your final executable. In your case it looks like you're missing std.dll. 

If you ever see this happen, what you can do is go to where haxe is installed on your computer and search the directory for the missing .dll file and see where it is. In my case, I found std.dll here:

C:\HaxeToolkit\haxe\lib\hxcpp\3,1,39\bin\Windows

ie, "%haxepath%\haxe\lib\hxcpp\3,1,39\bin\Windows"

In my own project, I had this problem with systools.dll, when I was using the systools library. I could copy it manually from the haxe library folder, but that's a pain. So I added a batch script to run in FlashDevelop.

In my FlashDevelop Project, I did:

Right-Click->Properties->Build->Post-Build Command Line, and entered this:

batch/PACKAGE.bat $(TargetBuild) $(BuildConfig)

And then I created a file in my project directory, under a new folder called batch/, called PACKAGE.bat, and entered this:

@echo off


set /p version=< %haxepath%\lib\systools\.current
set version=%version:.=,%


set origin=%haxepath%\lib\systools\%version%\ndll\Windows\systools.ndll
set destination=%cd%\export\windows\cpp\bin\systools.ndll


if %1==windows (
  if %2==release (
    :copy the necessary ndll files to the binary folder
    echo FY|xcopy %origin% %destination%
  )
)

Which has the effect of automatically copying over the newest version of systools.dll I have installed after my program compiles, so that I can safely just package up the bin folder. Let's explain how it works:

batch/PACKAGE.bat $(TargetBuild) $(BuildConfig)

This "post-build" command will look like this if I compile, say, Release Mode on Windows:

batch/Package.bat windows release

So the batch file receives "windows" and "release" as parameters 1 & 2.

Next:

set /p version=< %haxepath%\lib\systools\.current
set version=%version:.=,%

I need to grab the systools.dll file, but I don't want my batch file to make assumptions about what version I have installed, I just want it to grab the latest version. So I have it read the version information inside the haxelib directory and save it as a variable. Then I use that variable again in the next line as part of the directory to copy from:

set origin=%haxepath%\lib\systools\%version%\ndll\Windows\systools.ndll
set destination=%cd%\export\windows\cpp\bin\systools.ndll

These two lines set where I want to copy from and where I want to copy to.

if %1==windows (
  if %2==release (
    :copy the necessary ndll files to the binary folder
    echo FY|xcopy %origin% %destination%
  )
)

If we're compiling for windows in release mode, it copies the ndll file to the export folder. 

If you ever have dll files missing, you should be able to modify this script to handle that issue. 

Now as I close, it's very strange that you don't have std.dll in your bin directory -- you should NOT have to copy that manually, that always shows up for me and I've never had trouble with it, so maybe something else is going on. It should appear in export/windows/cpp/bin, and should appear right alongside your executable file (at least in windows).