On Apr 15, 2014, at 9:02 AM, Leif Hedstrom <zw...@apache.org> wrote:
> > On Apr 15, 2014, at 9:41 AM, James Peach <jpe...@apache.org> wrote: > >> On Apr 15, 2014, at 7:29 AM, zw...@apache.org wrote: >> ... >>> +# These are currently built separate, as part of building the lib/ tree, >>> using >>> +# the normal LuaJIT build system. We are using the .o's directly, instead >>> of the >>> +# luajit.a to avoid the linker from optimizing symbols away. We could maybe >>> +# switch to using the luajit.so, but that involves making sure it installs >>> safely >>> +# and cleanly. >> >> Can you elaborate on this? > > It doesn’t work with luajit.a, because it will optimize the symbols away. > Installing a luajit.so would work, but we risk conflicting with system > installs, so we’d want to rename it. But why would that happen? If it's optimizing the symbols because they are not used, then that would stop once you start using them. >>> -if BUILD_LUA_SUPPORT >>> + >>> +# On Darwin LuaJIT requires magic link options, otherwise it will crash in >>> luaL_openlibs() at startup. See >>> +# http://luajit.org/install.html. >>> traffic_server_LDFLAGS += @LUA_LUAJIT_LDFLAGS@ >>> -endif >> >> AFAICT nothing ever caused LUA_LUAJIT_LDFLAGS to be set. > > > > # On Darwin LuaJIT requires magic link options, otherwise it will crash in > luaL_openlibs() at startup. See > # http://luajit.org/install.html. > case $host_os in > darwin) > if test "x${enable_lua_support}" = "xLuaJIT"; then > LUA_LUAJIT_LDFLAGS="-Wl,-pagezero_size,10000 -Wl,-image_base,100000000" > fi > ;; > esac > > AC_SUBST(LUA_LUAJIT_LDFLAGS) > > > This has not changed with this patch. Is enable_lua_support ever set? J
