On 29/11/15 20:59, Gavin Wraith wrote:
I tried compiling Lua with static linking of UnixLib. The linker threw
this error:
gcc -o lua6 -O2 -Wall -Wextra -mfpu=vfp -static -mtune=cortex-a7 -DRISCOS
lua.o -Wl,-E liblua
liblua(ldo.o): In function `luaD_throw(lua_State*, int)':
ldo.c:(.text+0x104): undefined reference to `__cxa_allocate_exception'
ldo.c:(.text+0x118): undefined reference to `__cxa_throw'
liblua(ldo.o): In function `luaD_rawrunprotected(lua_State*, void
(*)(lua_State*, void*), void*)':
ldo.c:(.text+0x388): undefined reference to `__cxa_begin_catch'
ldo.c:(.text+0x39c): undefined reference to `__cxa_end_catch'
liblua(ldo.o):(.ARM.extab+0x30): undefined reference to `__gxx_personality_v0'
liblua(ldo.o):(.rodata._ZTIP11lua_longjmp[typeinfo for lua_longjmp*]+0x0):
undefined reference to `vtable for __cxxabiv1::__pointer_type_info'
liblua(ldo.o):(.rodata._ZTI11lua_longjmp[typeinfo for lua_longjmp]+0x0):
undefined reference to `vtable for __cxxabiv1::__class_type_info'
liblua(loadlib.o): In function `lookforfunc(lua_State*, char const*, char
const*)':
The above symbols relate to C++ exceptions and are provided by
libstdc++. If you link with g++, then these should be resolved.
loadlib.c:(.text+0x5d4): undefined reference to `dlsym'
loadlib.c:(.text+0x608): undefined reference to `dlerror'
loadlib.c:(.text+0x638): undefined reference to `dlopen'
loadlib.c:(.text+0x6b4): undefined reference to `dlerror'
liblua(loadlib.o): In function `gctm(lua_State*)':
loadlib.c:(.text+0x8cc): undefined reference to `dlclose'
collect2: error: ld returned 1 exit status
makefile:67: recipe for target 'lua6' failed
make: *** [lua6] Error 1
These are provided by libdl.
The ldo.c errors seem to be related to the use of longjmp. The loadlib.c errors
seem to imply that the linker cannot find
!GCC.arm-unknown-riscos.include.h.dlfcn .
That's a compiler include file which the linker doesn't use; you
need -ldl when linking.
Is it not possible to have dynamic loading with a statically linked UnixLib?
No, there is a static libdl for convenience, but it is a dummy library,
and the functions are NOOPs.
Imagine a binary statically linked to UnixLib which loads a library
at runtime that is dynamically linked to shared UnixLib. Hpw do you
resolve the two UnixLibs so that they are one? Bearing in mind that
the static one has already been resolved at build time and contains
no symbol data.
Compiling without the -static flag I still get the ldo.c errors, as above.
You have a missing -ldl, but as I say, it's a dummy library that does
nothing useful.
The source file ldo.c has changed in the update from v5.3.1 to v5.3.2
but there is no non-ANSI C stuff in it. Is there some library that I have
omitted from the makefile? v5.3.1 compiled without complaint, but now I
am stuck. What is all this __cxa and vtable stuff?
That's all C++ stuff, are you sure they haven't switched to C++?
Or is it still using g++ to compile lapi.c when it should be
using gcc? Did you figure that one out?
Lee.
_______________________________________________
GCCSDK mailing list gcc@gccsdk.riscos.info
Bugzilla: http://www.riscos.info/bugzilla/index.cgi
List Info: http://www.riscos.info/mailman/listinfo/gcc
Main Page: http://www.riscos.info/index.php/GCCSDK
