Icons not being generated


Since the latest update (OpenFL 2.1.7 & Lime 2.0.1) my app has stopped generating icons for Mac (not really problem as it’s for testing) but more importantly, Android - I’ve not tried iOS because of another issue which I’ve not looked into.

Switching back to 2.0.0-alpha.6 fixes the issue although with 2.0.0-alpha.7 I was finding my icons were missing certain elements for some reason.

Not sure what has changed over the last few releases but going from successful icon generation to nothing isn’t great.

Any help or guidance would be appreciated.


Are you building from source? If so, make sure you rebuild the Lime legacy binaries, which are used, currently, for icon generation from SVG

No, this is just using the latest ‘lime upgrade openfl’ release builds. No dev builds.

Also thought it might be related to my svg icon, but the standard openfl.svg doesn’t get generated either.

+1 I’m also running into the same issue. I’m using HaxeFlixel, and no matter how I specify it, I always end up with the default icon – not the svg.

Is there an easy, “full proof” way to generate the icon quickly without running my app on Android? I read a comment on the Haxe blog that “Windows explorer caches the icon so you have to change the name,” but it doesn’t mention which versions of Windows.

Edit: #derp. It turns out HaxeFlixel requires the icon to be way, way at the bottom of the file; there’s a heading section that reads:

<!--Place custom nodes like icons here (higher priority to override the HaxeFlixel icon)-->

Placing the icon tag here, works. You can put the actual icon file inside assets too.

@Greg209 do you get icons when using an OpenFL sample?

After trying…

lime create openfl BunnyMark
cd BunnyMark
lime test android

Still no icon I’m afraid and same for iOS (in XCode 5.1.1 there are no icon files created). This is built on a Mac 10.8.5. Out of curiosity, since the Lime 2.0.1 update, the first few lines of output from lime test/build … results in a series of file errors…

Error: [file_open,/var/folders/Fq/Fqa2NizCG+q+IXzIlRksQU+++TI/-Tmp-//temp_13242230.png]
Error: [file_open,/var/folders/Fq/Fqa2NizCG+q+IXzIlRksQU+++TI/-Tmp-//temp_3297009.png]
Error: [file_open,/var/folders/Fq/Fqa2NizCG+q+IXzIlRksQU+++TI/-Tmp-//temp_14228911.png]
Error: [file_open,/var/folders/Fq/Fqa2NizCG+q+IXzIlRksQU+++TI/-Tmp-//temp_3942886.png]
Error: [file_open,/var/folders/Fq/Fqa2NizCG+q+IXzIlRksQU+++TI/-Tmp-//temp_13154064.png]

No such errors when building with lime 2.0.0-alpha.6.


Any one else having these icon problems?

I’ve retested on the latest OpenFL/Lime and after using ‘lime create openfl:DisplayingABitmap’ and building it, I get no icons on Android and no icons are shown in XCode after a ‘lime update ios -debug’.

I’ve seen a few icon related messages in the forum so not sure if they are related.



If you’re building from source, make sure you built both “lime rebuild mac” as well as “lime rebuild mac -Dlegacy”

This is straight from the latest release builds - not built from sources.

Are there any tests I could try to identify where a failure may be occuring to help track it down?


Hmm, I’m not sure if it’s possible to get much more information without doing a source build

You could do “-verbose”, and see if that provides any more detail

Adding -verbose revealed this for each icon creation command.

 - Running command: neko /usr/lib/haxe/lib/lime/2,0,4//svg.n process embeds/openfl.svg 16 16 /var/folders/Fq/Fqa2NizCG+q+IXzIlRksQU+++TI/-Tmp-//temp_1877431.png
Error: [file_open,/var/folders/Fq/Fqa2NizCG+q+IXzIlRksQU+++TI/-Tmp-//temp_1877431.png]
 - Running command: java -Dapple.awt.UIElement=true -jar /usr/lib/haxe/lib/lime/2,0,4//templates/bin/batik/batik-rasterizer.jar -d /var/folders/Fq/Fqa2NizCG+q+IXzIlRksQU+++TI/-Tmp-//temp_1877431.png -w 16 -h 16 embeds/openfl.svg
About to transcode 1 SVG file(s)

Error while converting files: 
 Error: unable to create output directory

It turns out, permissions on /var/folders : drwxr-xr-x root:wheel

So I can’t write to the folder through my user login.

Does that shed any light? I can obviously change the permission but never had to before and it does indeed correct the problem and I’m not sure on the implications of changing those permissions although I can’t see it doing any harm.

Thanks for pointing -verbose out.

This is the location of $TMPDIR on your system. It’s strange that it would have non-user-writable permissions. I wonder if this is an OS version difference, common somehow, or how this occurred. I wonder if “/tmp” would be better on OS X