[Date Prev][Date Next][Thread Prev][Thread Next]
- Subject: Re: dynamic linking problem with two(!??) luaxlib funcs
- From: mfmorss@...
- Date: Fri, 24 Feb 2006 15:32:35 -0500
Your diagnosis sounds right. But my very limited understanding is that
linking every future shared library against liblua.a will (1) create much
bigger *.so files by filling them up with all the code that goes into
liblua.a and (2) create multiple instances of the functions defined in
liblua.a, which could give rise to weird symptoms -- so I've been told.
There was some previous correspondence on this point when I was trying to
get Lua set up with dynamic linking in the first place.
AIX does let me create an "export file" for dynamically linked libraries,
though, and then link with -bE:exportfile instead of -bexpall. There is a
way to make the compiler do most of the editing. That would give me manual
control over the main program exports, and I could then just edit this file
by hand to include luaL_ref and luaL_typerror. On the very remote chance
that another AIX jockey is lurking here, I include this reference:
That, however, would make the stardard AIX build a royal pain. Maybe a
nicer solution, from the viewpoint of AIX users, would be for the
maintainers to fake some calls to these functions (and any other luaL funcs
not called in the main code) directly in, say, some file that is only
linked if the build is for AIX. Then in those, I admit, comparatively rare
cases where Lua were being installed on AIX, -bexpall would see the fake
calls and export the functions.
Maybe xlc would figure out that the fake calls weren't ever used?!
Mark F. Morss
Principal Analyst, Market Risk
American Electric Power
Sent by: Lua list
Re: dynamic linking problem with
02/24/2006 02:20 two(!??) luaxlib funcs
Please respond to
Perhaps the problem is that these two lauxlib functions are not used by
the main program or any other lauxlib functions, so they aren't included
in the main program. This is possible, if the AIX linker includes only
the referenced functions in a given object file. The solution, then, is
to make a shared library out of all the files that go in liblua.a, and
link both the main program and your extension library against this
shared library. If I'm not mistaken, this is the recommended way of
doing things anyway, when extensions are loaded as shared libraries. I
hope this helps.