I'm trying to build a DLL to be used in a Mozilla Firefox extension. I'm using Cygwin in Windows 7. I have the C code working fine and it builds ok:
#include<stdio.h>
#include<windows.h>
BOOL WINAPI DllMain(HINSTANCE hinstDLL, DWORD fdwReason, LPVOID lpvReserved)
{
return TRUE;
}
extern "C"
{
__declspec(dllexport) int add(int a,int b) //int a,int b
{
return(a+b);
}
}
I followed the instructions here: Build a DLL to be used by Mozilla js-ctypes.
The problem is that when I try to include a different library, the js-ctypes cannot read the DLL afterwards:
[10:20:53.575] Error: couldn't open library C:\Users\admin\workspaces\Extensions\formfinder\components\test.dll @ chrome://formfinder/content/overlay.js:104
All I'm adding to my C file is #include <ZZ.h>
at the top, which is then complemented by the make commands:
i686-w64-mingw32-g++ -c -I/usr/local/include/NTL -I/usr/local/include test.cc
i686-w64-mingw32-g++ -shared -o test.dll test.o -Wl,--out-implib,libmylib.dll -Wl,-e_DllMain@12
I'm using i686-w64-mingw32-g++
instead of gcc/g++
because the DLL can't be opened otherwise. I'm not sure why though.
Any help would be appreciated.
I don't quite get what is asked, but probably why the Cygwin gcc (or mingw-w64 gcc) is producing a DLL you cannot
ctypes.open()
.DLLs produced by the Cygwin gcc do have external dependencies on some Cygwin DLLs, at least
cygwin1.dll
providing a posix abstraction. Shipping these DLLs with your add-on is a pain and not really a sane thing to do.You'll want to use a mingw compiler (e.g. the
i686-w64-mingw32-g++
one). You could also use a Microsoft or Intel compiler instead.OK, mingw-w64 it is for now:
Alright, our DLL imports
kernel32.dll
andmsvcrt.dll
and nothing unexpected, and also exports ouradd
.Lets try it, then:
Produces an output of:
8
.Next, all binaries should be ASLR enabled.
Turns out, it isn't (no dynamicbase)
So let's improve our linker command:
Alright then.
But this is not all, unfortunately. When compiling
C++
and using certain features, the linker will automatically link in thestdlibc++
, e.g. when usingstd::string
.Adding a
std::string
to our source, recompiling/relinking, and anotherobjdump
tells us:In that case, you'd have to ship those libaries as well (make sure to
peflags
the ASLR bits and follow the license), or avoid anything that could produce an exception or would otherwise requirestdlibc++
. Or you can static link the stuff:Static linking will blow up the output DLL size, of course.