Enrico Tassi <gareuselesi...@debian.org> writes: > Please try the attached patch, I'm planning to upload this to unstable > as soon as possible.
In the liblua5.1-0 package built from your 5.1.4-12 patch, the
shlibs file contains:
liblua5.1-c++ 0 liblua5.1-0
liblua5.1 0 liblua5.1-0
Because liblua5.1-c++.so.0 did not exist in earlier binary
packages, I think you should add (>= 5.1.4-12) to that line.
Differences between the dynamic symbols of liblua5.1.so and
liblua5.1-c++.so:
- OK: liblua5.1-c++.so has typeinfo objects for lua_longjmp and
lua_longjmp*.
- OK: liblua5.1-c++.so has references to libstdc++.so.6 and
libgcc_s.so.1, and to some symbols of those.
- OK: liblua5.1-c++.so uses fscanf; liblua5.1.so uses __isoc99_fscanf.
This happens because some GNU extensions conflict with C99 additions
and are therefore disabled for C by default.
- OK: liblua5.1-c++.so uses isalnum et al; liblua5.1.so uses
__ctype_b_loc. This is because <ctype.h> does not define
isalnum as a macro when compiled as C++.
- OK: liblua5.1.so has references to _setjmp and _longjmp.
- OK: liblua5.1-c++.so defines lua_ident; liblua5.1.so does not.
This is because lapi.c defines lua_ident as const char[], which
implies static in C++. Applications should not use lua_ident,
because it is neither declared in any header nor documented the
Lua 5.1 Reference Manual.
> I've also added one more test to your test file, and now it
> seems to be able to require C modules.
I see you also corrected the exit code.
> Also note the include <lua.hpp> that adds extern "C" and
> includes also auxiliary lua headers.
That is somewhat redundant now that you have extern "C" in
LUA_API. Originally, I thought the extern "C" should only be
visible when Lua itself is being compiled; for applications, the
header should behave as in previous versions. Now though, I
think you made the right choice. Having extern "C" in LUA_API
lets application programmers use e.g. "lua.h" without wrapping it
in extern "C" { ... } in the application source; and an
application doing that is also portable to Lua installations
built in C++ from unmodified upstream sources. Such an
application is not portable to Lua installations built in C from
unmodified upstream sources, but that combination would probably
suffer from memory leaks or worse at runtime anyway.
I have not tried liblua5.1-c++.so.0 with Bos Wars yet. Bos Wars
has a Python-based build system that may take some time for me to
figure out.
Thank you for your effort.
pgpnEMf5Xqe92.pgp
Description: PGP signature
