Reimplement linker hack

I think this version of the linker hack has a better change of working on more compilers. If the
symbols from lapi.o are being exported, then including Pallene symbols there should probably do the
trick! As a bonus, we can get away with not modifying the makefile.

vm/PALLENE-UPDATING

@@ -14,29 +14,9 @@ For the next release, we should consider preparing a proper patch file.
 
 2) Add the Linker Hack to the lua.c
 
-    /*
-    ** PALLENE LINKER HACK
-    **
-    ** When we build the final "lua" executable, bundling it with the "liblua.a" library, the linker
-    ** only includes symbols from the object files where at least one of the symbols of the module is
-    ** used by the executable itself. This is a problem for the Pallene runtime library, because those
-    ** symbols are only used by extension modules, which we expect to dynamically link. One hacky
-    ** workaround I found is to force the "lua" executable to reference one of the symbols from the
-    ** pallene_code, as done below.
-    */
-    char *pallene_tag_name(int);
-    char *(*PALLENE_LINKER_HACK)(int) = pallene_tag_name;
+    See the end of the "lapi.c"
 
 3) Copy the pallene_core files
 
     vm/src/pallene_core.h
     vm/src/pallene_core.c
-
-4) Update the src/Makefile
-
-   - Add pallene_core.o to the CORE_O list
-   - Add the pallene_core.o target
-
-    pallene_core.o: pallene_core.c pallene_core.h lapi.h ldo.h lfunc.h \
-      lobject.h lstate.h lstring.h ltable.h lvm.h lmem.h lobject.h lstate.h \
-      lstring.h ltm.h ltable.h

vm/src/Makefile

@@ -26,14 +26,14 @@ MYLIBS=
 MYOBJS=
 
 # Special flags for compiler modules; -Os reduces code size.
-CMCFLAGS=
+CMCFLAGS= 
 
 # == END OF USER SETTINGS -- NO NEED TO CHANGE ANYTHING BELOW THIS LINE =======
 
 PLATS= guess aix bsd c89 freebsd generic linux linux-readline macosx mingw posix solaris
 
 LUA_A=	liblua.a
-CORE_O=	lapi.o lcode.o lctype.o ldebug.o ldo.o ldump.o lfunc.o lgc.o llex.o lmem.o lobject.o lopcodes.o lparser.o lstate.o lstring.o ltable.o ltm.o lundump.o lvm.o lzio.o pallene_core.o
+CORE_O=	lapi.o lcode.o lctype.o ldebug.o ldo.o ldump.o lfunc.o lgc.o llex.o lmem.o lobject.o lopcodes.o lparser.o lstate.o lstring.o ltable.o ltm.o lundump.o lvm.o lzio.o
 LIB_O=	lauxlib.o lbaselib.o lcorolib.o ldblib.o liolib.o lmathlib.o loadlib.o loslib.o lstrlib.o ltablib.o lutf8lib.o linit.o
 BASE_O= $(CORE_O) $(LIB_O) $(MYOBJS)
 
@@ -218,8 +218,5 @@ lvm.o: lvm.c lprefix.h lua.h luaconf.h ldebug.h lstate.h lobject.h \
  ltable.h lvm.h ljumptab.h
 lzio.o: lzio.c lprefix.h lua.h luaconf.h llimits.h lmem.h lstate.h \
  lobject.h ltm.h lzio.h
-pallene_core.o: pallene_core.c pallene_core.h lapi.h ldo.h lfunc.h \
- lobject.h lstate.h lstring.h ltable.h lvm.h lmem.h lobject.h lstate.h \
- lstring.h ltm.h ltable.h
 
 # (end of Makefile)

vm/src/lapi.c

@@ -1453,3 +1453,17 @@ LUA_API void lua_upvaluejoin (lua_State *L, int fidx1, int n1,
 }
 
 
+/*
+** PALLENE LINKER HACK
+**
+** When we build the final "lua" executable, bundling it with the "liblua.a" library, the linker
+** only includes symbols from the object files where at least one of the symbols of the module is
+** used by the executable itself. This is a problem for the Pallene runtime library, because those
+** symbols are only going to be used by the extension modules, which we expect to dynamically link.
+** The hacky workaround that we found is to compile the pallene_core stuff as part of the lapi.o,
+** isntead of its own object file.
+**
+** As a bonus, we also avoid having to modify the Makefile. Conveniently, the set of header files
+** that lapi.c depends on is a superset of the header files that pallene_core.c needs.
+*/
+#include "pallene_core.c"

vm/src/lua.c

@@ -657,16 +657,3 @@ int main (int argc, char **argv) {
   return (result && status == LUA_OK) ? EXIT_SUCCESS : EXIT_FAILURE;
 }
 
-/*
-** PALLENE LINKER HACK
-**
-** When we build the final "lua" executable, bundling it with the "liblua.a" library, the linker
-** only includes symbols from the object files where at least one of the symbols of the module is
-** used by the executable itself. This is a problem for the Pallene runtime library, because those
-** symbols are only used by extension modules, which we expect to dynamically link. One hacky
-** workaround I found is to force the "lua" executable to reference one of the symbols from the
-** pallene_core, as done below.
-*/
-char *pallene_tag_name(int);
-char *(*PALLENE_LINKER_HACK)(int) = pallene_tag_name;
-

vm/src/pallene_core.h

@@ -6,23 +6,29 @@
 #ifndef PALLENE_CORE_H
 #define PALLENE_CORE_H
 
+// This list on includes should include basically everything we need.
+// It is copied from lapi.c (grep for PALLENE LINKER HACK for more details)
+
 #include "lua.h"
 #include "lauxlib.h"
 #include "lualib.h"
 
 #include "lapi.h"
+#include "ldebug.h"
 #include "ldo.h"
 #include "lfunc.h"
 #include "lgc.h"
+#include "lmem.h"
 #include "lobject.h"
 #include "lstate.h"
 #include "lstring.h"
 #include "ltable.h"
+#include "ltm.h"
+#include "lundump.h"
 #include "lvm.h"
 
 #include <math.h>
 
-
 #define PALLENE_NORETURN __attribute__((noreturn))
 #define PALLENE_UNREACHABLE __builtin_unreachable()