Building JS library from scratch

[mcarans]

I noticed something while examining the executable with the statically linked JS: It exports hundreds of JS_* functions and many with C++ mangled names too, all from the JS library. If the reason we are building this exe is to avoid presenting a js32ECMAv5.dll as part of the binary distribution, then I think that exporting practically the entire JS library from the exe is more sus than the dll. If I were Microsoft and saw all those exports in the exe I would be asking for clarifications.

I don't have the exe handy now but tomorrow I will post a screenshot of what gets exported. Normally the Oolite executable (and most games executables for that matter) are expected to export just 2 functions: The NVidia and AMD functions required in dual-GPU laptops for telling the gfx driver that the discreet GPU must be used for the game.

It's certainly good that we now know how to use static JS linking if we want to, but I would recommend not replacing the dll with static linking at this stage. It just seems more straightforward if the js dll is separate and the exe remains "clean".

That is most likely related to the settings used when configure was called. I see in the configure script:

Code: Select all

# Check whether --enable-shared-js or --disable-shared-js was given.
if test "${enable_shared_js+set}" = set; then
  enableval="$enable_shared_js"
  if test "$enableval" = "yes"; then
    DISABLE_SHARED_JS=0
  elif test "$enableval" = "no"; then
    DISABLE_SHARED_JS=1
  else
    { echo "configure: error: Option, shared-js, does not take an argument ($enableval)." 1>&2; exit 1; }
  fi
fi


if test "$DISABLE_SHARED_JS" = "1" ; then
  cat >> confdefs.h <<\EOF
#define STATIC_EXPORTABLE_JS_API 1
EOF

else
  JS_SHARED_LIBRARY=1
fi

[mcarans]

I noticed something while examining the executable with the statically linked JS: It exports hundreds of JS_* functions and many with C++ mangled names too, all from the JS library. If the reason we are building this exe is to avoid presenting a js32ECMAv5.dll as part of the binary distribution, then I think that exporting practically the entire JS library from the exe is more sus than the dll. If I were Microsoft and saw all those exports in the exe I would be asking for clarifications.

I don't have the exe handy now but tomorrow I will post a screenshot of what gets exported. Normally the Oolite executable (and most games executables for that matter) are expected to export just 2 functions: The NVidia and AMD functions required in dual-GPU laptops for telling the gfx driver that the discreet GPU must be used for the game.

It's certainly good that we now know how to use static JS linking if we want to, but I would recommend not replacing the dll with static linking at this stage. It just seems more straightforward if the js dll is separate and the exe remains "clean".

Apparently the leaking can be fixed by doing:

Code: Select all

objcopy --remove-section=.drectve libjs_static.a libjs_clean.a

Or if that doesn't work effectively, then before the ar step, something like:

Code: Select all

for f in *.o; do
    objcopy --remove-section=.drectve "$f"
done

[another_commander]

Apparently the leaking can be fixed by doing:

Code: Select all

objcopy --remove-section=.drectve libjs_static.a libjs_clean.a

This was the fix. All good now, JS functions are no longer exported and all is back to normal.

[another_commander]

The debug build of Oolite (make debug=yes) is currently broken for the modern and legacy builds with the static js update. Modern was broken also prior because there was no libjs32ECMAv5dbg library to link against and the release js - static or not - is not suitable for linking with the game's debug build.

The solution would be to create also a debug static js flavor and include it in the build system. That would allow successful linking. Note that for the debug build to work when using the debug static JS, Oolite must be built with the macro STATIC_JS_API defined.

[another_commander]

Having looked at the debug legacy build a bit, the JS debug static import library is 30MB in size. I don't think I'd want to check-in to github a binary of that size. Maybe it would be preferable if we keep the debug build linked to the js32ECMAv5dbg.dll That build is not for any kind of distribution anyway and is only expected to be used by developers for internal testing.

We'd still need the modern build equivalent of js32ECMAv5dbg.dll though.

[mcarans]

Having looked at the debug legacy build a bit, the JS debug static import library is 30MB in size. I don't think I'd want to check-in to github a binary of that size. Maybe it would be preferable if we keep the debug build linked to the js32ECMAv5dbg.dll That build is not for any kind of distribution anyway and is only expected to be used by developers for internal testing.

We'd still need the modern build equivalent of js32ECMAv5dbg.dll though.

I'll try adding the debug dll and static lib to the Spidermonkey package so it can be installed by pacman.

[another_commander]

Please make sure that the libjs32ECMAv5.dll.a import library for the debug dll is included too. This is the one to be used for the make debug=yes build.

[mcarans]

Please make sure that the libjs32ECMAv5.dll.a import library for the debug dll is included too. This is the one to be used for the make debug=yes build.

There was an additional cast change (jsbytecode*) needed for the JS debug compilation to succeed: https://github.com/mcarans/oolite_mozjs ... 38dcdf0ad3:

Code: Select all

#define JS_GET_SCRIPT_ATOM(script_, pc_, index, atom)                         \
    JS_BEGIN_MACRO                                                            \
        if ((jsbytecode*)(pc_) < (script_)->code ||                           \
            (script_)->code + (script_)->length <= (jsbytecode*)(pc_)) {      \
            JS_ASSERT((size_t)(index) < js_common_atom_count);                \
            (atom) = COMMON_ATOMS_START(&cx->runtime->atomState)[index];      \
        } else {                                                              \
            (atom) = script_->getAtom(index);                                 \
        }                                                                     \
    JS_END_MACRO

The new release with debug js32ECMAv5dbg.dll, libjs32ECMAv5dbg.dll.a and libjsdbg.a is here: https://github.com/OoliteProject/oolite ... /tag/0.0.9

[another_commander]

I am testing it right now. Stand by for feedback on github real soon.

[mcarans]

I am testing it right now. Stand by for feedback on github real soon.

I've made the changes you suggested in the PR.