Compilation error with jsapi.h in VS19 with esr78


I have build spiderMonkey(esr78) in windows by following the steps mentioned in official documentation. For more info regarding build process see this link,
When I’m tryiing to build my testapp.cpp using spiderMonkey in visual studio 2019,it’s giving compilation error from GCPolicyAPI.h(line:70) whenever i’m adding jsapi.h in my program.

Error: error C2338: Pointer type not allowed for StructGCPolicy

If I remove “jsapi.h” the program compiles and runs fine.

// testapp.cpp:

#include <jsapi.h>
#include <js/Initialization.h>
int main(void) {
if (!JS_Init()) return 1;
return 0;

[Note: preprocessor used: STATIC_JS_API in project properties]

Can anyone please help me on this, what’s wrong I’m doing here?

We’ve run into this as well, and work around it by defining a specialization of GCPolicy<void*> wherever GCPolicyAPI.h is included. (See link below.) Looks like you might be including it indirectly and that’s why this is happening.

1 Like

thanks a lot …it’s worked with esr78…but not working with 90 …you have any workaround with 90 ?

from 85 ( ), the problematic case uses JS::detail::RootListEntry* instead of void*.
So, the workaround for MSVC needs to define the speciallization for detail::RootListEntry* instead of void*.

1 Like

I think for your example we want to avoid using STATIC_JS_API if you are building a .dll. I tried your example and run into Bug 1716147 which I made the following workaround for:

With both of these fixed, I am able to build a simple spidermonkey DLL demo on Windows. I am testing with v91 (the next upcoming ESR).

I also used the mach build workflow described here. I had to use ac_add_options --disable-jemalloc for embedding to avoid needing the more complicated build steps that Firefox uses.

I’ve filed Bug 1716247 to fix the GCPolicyAPI stuff on MSVC (and make the code less gross for everyone…). We should be able to get this small fixes into the ESR-91 version so at a first approximation MSVC should work for external embedders (though probably want to compile spidermonkey itself with the normal clang workflow…).

thank you …with esr78 shall I continue with this :