[gccsdk] GCC 4.7.4 errors

Lee Noar leenoar at sky.com
Mon Nov 30 06:10:26 PST 2015


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.





More information about the gcc mailing list