[SOLVED] Could not load module std@get_env__1

Help
#1

Hi there.
Regarding the game I just released (made a post in the showcase section), I have some feedback about an error message :

It happened on Windows 8.1 and Windows 7.
It works fine on my Windows 8 version…

Couldn’t find anything relevant on Google, any guess ?

If you want to test it, here is the direct download link to the “standalone/embed” version :
http://abstractpixelgames.com/downloads/AbstractPixelRun-0.8.1-Windows-embed.zip

[Edit] The current public verison is the “no embed” one :
http://abstractpixelgames.com/downloads/AbstractPixelRun-0.8.1-Windows.zip

I just asked on the HaxePunk forum too…

#2

I made some progress : it works fine if I don’t embed assets and sounds in the .exe file…

You know, with the embed=false in the project.xml

<assets path="assets/audio" rename="audio" include="*.wav|*.ogg" unless="flash" embed="false" />

The result is messy, but it works.

Any guess on how to get a clean and working exe file with all in it ?
Or at least how to put evrything but the exe in a subfolder ?

It’s worse noting that the use of embed=true affects the assets but the .dll too… which is strange.

#3

Hi,
Check this https://github.com/openfl/lime-tools/issues/68 simular issue fixed.

#4

Ok, I did that.
It helped me to understand the project.xml better too, which is fine, thanks !

But I’m not convinced it changed anything, as the file has still the same weight.
Moreover, it worked fine on my windows 8 computer, so I guess the std lib was already embeded for good.
Don’t know why it wasn’t found on windows 7 and 8.1…

I sent the new exe to my testers, I’m waiting for their appreciation.
Meanwhile I uploaded the “no embed” messy version on my website !

#5

Hi !
It didn’t solve the issue.
Same problem with the packed version on windows 7 and windows 8.1, even with the ndll markups.

My guess is it’s correctly embeded, but for an unknown reason these OS don’t find it.
Are there know issues about windows builds, targetting other windows versions ?

I could try to generate it from windows XP, and see what happened then.

#6

Are you trying to do a -static build, or is this the same project with the std.ndll sitting next to the executable?

#7

I’m not sure of the answer here :sweat_smile:
I use sublime text package with the C++ release target… using embed=true in the package.xml
It seems to pack everythig in a single file application, which works fine on MacOSX, but some users had problems with my windows build.

But the same exe works fine on my system !
Could it find the std lib locally ?

With embed=false, there’s a std.dll (not Ndll) standing next to the executable… and this works for every user.

#8

Huh, that’s strange – embed=true is not supposed to affect the std.ndll, it should still have this unless you do a -static build

#9

You’re right, and that’s what I realised a few hours ago !

Stangely the exe worked alone on my computer, but maybe nowhere else (using my local libs, maybe).
Maybe I took the idea that it was a standalone executable working on MacOSX simultaneously… MacOSX generates standalone applications, which work well everywhere :smile:

I just sent this “solo” exe, but this time whith the associated dlls to my testers, and I guess it’ll work fine… I’ll know soon.

So the -static build could be the solution to pack everythting in a single file ?
I’ll have to investigate that… but you wrote that Lime 2 is needed to do that, and I’m stuck with previous version to use HaxePunk :cry:

Thanks anyway !

#10

Well, OS X generates “standalone” applications that really are a directory, the OS makes the directory appear to be a single file :wink:

Yeah, if you want a single executable, static builds might do it – this is supported in Lime 2, but could (probably?) be backported to Lime legacy for use with OpenFL 2 (not “next”) native builds.

However – I don’t include OpenAL on static builds right now due to the LGPL license on it. I don’t want people to unexpectedly have to open source their code :wink: