Re: undefinied symbols on linking

[Mike Swingler <mike.swingler@...>]

On Feb 13, 2013, at 2:31 AM, Philipp Kraus <philipp.kraus@flashpixx.de> wrote:

> Am 13.02.2013 um 00:20 schrieb Stephen Irons:
> 
>> On 13/02/13 11:24, Philipp Kraus wrote:
>>> Hello,
>>> I have compiled LUA from the sources under OSX 10.6 and wrap the LUA functions with a C++ class.
>>> On some programs I can use my class without any problems and on some I will get linker errors:
>>> 
>>> Undefined symbols:
>>>  "_lua_atpanic", referenced from:
>>>  "_luaL_openlibs", referenced from:
>>>  "_luaL_newstate", referenced from:
>>>  "_lua_remove", referenced from:
>>>  "_lua_close", referenced from:
>>>  "_lua_pcallk", referenced from:
>>>  "_lua_tolstring", referenced from:
>>>  "_luaL_loadstring", referenced from:
>>> 
>>> I have build the LUA lib with the cppdefine LUA_USE_MACOSX but I can not found a problem on my
>>> code, because I compile the different codes in the same way. I have build only a *.a file (static lib)
>>> 
>>> Can anybody help me or send me a tip?
>>> 
>>> Thanks
>>> 
>>> Phil
>> 
>> This is probably a linker problem, so you will not find the solution by looking at the code.
>> 
>> Most likely, the libraries to link to the program are specified in the wrong order.
>> 
>> Some linkers only look for unresolved symbols in subsequent libraries in the list of libraries. So if you specify libraries in the wrong order you can get unresolved symbols.
>> 
>> For example, imagine
>> 
>> * main program in main.c which calls function A
>> 
>> * Function A calls function B
>> 
>> * Function A is provided by liba.
>> 
>> * Function B is provided by libb.
>> 
>> If the libraries are presented in the order main.o liba libb, then the link work correctly. It will load main.o and find that symbol 'A' is unresolved. It will then look in liba; it finds find symbol 'A', but now needs symbol 'B'. This is not in main.o or liba. The linker then looks in libb and find symbol 'B', so the link completes correctly.
>> 
>> But linking in the order main.o libb liba will end up with unresolved symbol 'B'. This is because the linker first links in main.o, and find that symbol 'A' is unresolved. The linker then looks in libb. At this stage, nothing needs its symbol 'B', so the linker discards everything from this library. The linker then looks at liba; it finds symbol 'A', loads it, and now needs symbol 'B'. But symbol 'B' is not provided by main.o or liba, so it remains unresolved. There are no more libraries to link, so the linker reports the error.
>> 
>> Check that your makefile or linker command line presents the libraries to the linker in the right order. It can be difficult to find the right order, especially if you have circular dependencies between libraries.
> 
> All programs are used on linking equal order of the libraries and the same libs. I have found http://lua-users.org/wiki/BuildingLua so I have rebuild my LUA lib and my programs. Can be a difference on the library? Should I build a shared or a static library on OSX?

Building a shared vs. a static library is a tradeoff of complexity. If you have multiple executables which all need Lua, a shared library allows you to do that with the minimum disk space, but then each of the executables needs to know where that library lives relative to an @rpath. A static library is simply included in the executable in which it is linked, and if you only have one, that is likely the most straightforward approach.

Regards,
~Mike