Compiling native extension lib for Windows


Since native extension manual lack of details I have some problems/questions. Also I couldn’t find any Windows example.

As far as I know we can’t use dynamic or shared libs like .dll or .so

I’m trying to compile lib on Linux with mingw32 (6.3) for windows. I know this is not the best way to do it. It is better to build on windozz… But I don’t have a windows box. (Windows dev virtualbox is 20gb! - damn it!)

I try to build static lib(.a)

x86_64-w64-mingw32-g++ -static-libgcc -static-libstdc++ -c -o AABB.o // Also try it without -static-libgcc -static-libstdc++ flags
x86_64-w64-mingw32-ar rcs libaabb.a AABB.o
x86_64-w64-mingw32-ranlib libaabb.a

Unfortunately build can’t resolve symbols…

Since Windows build uses cl.exe and link.exe (Linux native extensions error: Invalid lib - 'libs': 'c++' ext.manifest) it is unclear for dummies like me to how to use flags and libs in manifest.

I desperately try these but of course I fail :slight_smile:

   linkFlags:  ["/link libaabb.a"]
   libs:       ["libstdc++-6.dll", "libgcc_s_dw2-1.dll"]

Which flags and libs are available and how can I(we) use them in manifest? Or sould we?

Thank you in advance for any help you can provide…

1 Like


Agreed, we need to document this more. And I’ll add a win32 extension example as well.

For your use case, you should use the “.lib” extension for libraries on windows. And you don’t need to add any libs flags to add your own provided lib (we do that for you).

As for the C++ implementation, you shouldn’t need to link in the C++ dll’s either.

If you do need to add a library from visual studio, you would write their file name like so:

   libs:       ["Ws2_32.lib"]

There (a little) more information here regarding how to remove debug functionality from the engine. Notice that we specify the windows libraries by their full filename.

1 Like


Thank you for your explanations.
Then I have a mingw32 problem cause my lib doesn’t build with Defold. I’m going to investigate it.

1 Like


I believe I’m doing something wrong. I know this has nothing to do with you. But if you can give me some tips or show me the way I’ll be glad…

Whatever I try, I am almost sure that the lib is not compiling with Defold. It acts like the lib is not there and always return unresolved external symbol error(with lib or as usual without lib).
Most importantly, I never receive any lib related error from Defold yet. And I try a lot, lots of stuff :slight_smile:

So, I’m simply building aabb.lib. Looks like this is the way of building a static lib:

x86_64-w64-mingw32-g++ -O3 -std=c++11 -c -o aabb.obj 
x86_64-w64-mingw32-ar r aabb.lib aabb.obj 
x86_64-w64-mingw32-ranlib aabb.lib

And I put the lib in /lib/win32 folder (also try to rename it; /lib/x86_64-win32)

I’m not sure if this is about the mingw32 compiler or not. I made a simple cpp for testing and build the .exe with aabb.lib for windows. Looks like it work on Windows… This error message comes from “aabb.lib” on Windows terminal and it is a correct warning.


I build it with:

x86_64-w64-mingw32-g++ -O3 -std=c++11 -mconsole -static -static-libgcc -static-libstdc++ -o test-terminal.exe -L. test.cpp  -laabb

Do you have any idea why I can’t build it with Defold? (Yes I know, I should build it on Windoz :disappointed_relieved: )



So I have a chance to build lib on Windows with VS2017
According to this I use command line as instructed:

cl /c /EHsc
lib aabb.obj 

This one fails on Defold with unresolved external symbol errors

When I build it in the VS 2017, It fails silently(just with the warnings) on Defold.

My settings in VS2017

Any clue?

1 Like


Hi @selimanac!
I cannot pinpoint exactly where things go wrong here, would you mind inviting me to your project, and I’ll take a look? (



I would be really grateful if you can , because I am stuck at that point.

It is on Github:
I don’t have the VS solution right now with me. But I can provide it in a few hours.
Looks like it is about the compiler flags on VS. Because the lib size is so big comparing to other platforms.

1 Like


Visual Studio 2017 solution is attached (14.9 KB)

1 Like


First, you need to have the code generation set to “Multi threaded”, in order to not mix C runtimes:


Also, putting your lib in “win32” doesn’t really work for both 32/64 bit Win32 since the library itself is only either 32bit or 64 bit. So, put your library in the proper “x86-win32” or “x86_64-win32” folder, depending on which one you wish to use.

Latsly, there seems to be an issue with how we bundle Win32 right now when specifying 64 bit bundle. It will build 32 bit executable as well. I’ll fix that, but the current workaround is to supply both a 32bit and a 64 bit library, so it can build both.



Here is what I did:

  • I created a clean/new “static library” project in VS2017 with default settings.

  • I change the runtime libs to /MT as you suggested for x86 and for 64 release builds

  • Build it for x86 and 64 on VS

  • Renamed the folders for architectures (x86… _64…)

  • I clean up all cache files from project folder and also from …/Library/Application Support/Defold/cache

  • Build it with Defold

  • Defold silently failed with just the warnings without any errors.

  • Default VS static lib project is for precompiled headers. I also try to build lib without precompiled headers. Build failed on Defold too.

That should be really easy process for a simple c++ file… but… I hate Windoz I hate windozzz.



I’m wondering about this, what platform are you running the editor from? What version of the editor are you running?



MacOS 10.13.3


I just created a quick and simple test project and I add you to the team(I hope you don’t mind)
It is just a very basic lib using these two tutorials. Nothing more. Just changed the /MT.

It includes the VS project in lib-src/StaticLibrary.

When I try to bundle this project for windows on Mac with Defold it silently fail(without any errors).

1 Like


Great! Thx, I’ll take a look!



Hi again! What the name of your test project? I have so many to browse through :slight_smile:



“Win32-Native-Extension” :smiley:

1 Like


Now I got the same silent treatment from our tools doh

In the meantime we’re fixing that, here’s the actual error log for you. It doesn’t reveal anything obvious, but if you search for “MSDN C1900”, you’ll find the error page from Microsoft: C1900:

MathFuncsLib.lib(MathFuncsLib.obj) :
fatal error C1900: 
LINK : fatal error LNK1257:

(yes, that’s all info link.exe gave us)

Their documentation mentions a mismatch between tools from various stages, and I suspect that this is due to our engine is built with MSVC2015, whereas your libraries are built with MSVC2017. Our linker might not like that.
I think you have two options:

  • Rebuild the library using MSVC2015
  • Just have the library source files (.cc) as part of the extension (for now) and let the NE server built everything for you.


Did I mention that I hate windozz :smiley:
Thank you very much @Mathias_Westerdahl
At least we know the problem now.