undefined symbols (was: Re: Architecture mixup)

[Ian Wadham]

On 18/05/2012, at 6:11 AM, Ryan Schmidt wrote:

> On May 17, 2012, at 01:25, Ian Wadham wrote:
> 
>> Linking CXX executable ktuberling.app/Contents/MacOS/ktuberling
>> Undefined symbols for architecture x86_64:
>> "KStandardGameAction::gameNew(QObject const*, char const*, QObject*)", referenced from:
>>    TopLevel::setupKAction()      in toplevel.o
>> "KStandardGameAction::load(QObject const*, char const*, QObject*)", referenced from:
>>    TopLevel::setupKAction()      in toplevel.o
>> "KStandardGameAction::save(QObject const*, char const*, QObject*)", referenced from:
>>    TopLevel::setupKAction()      in toplevel.o
>> "KStandardGameAction::print(QObject const*, char const*, QObject*)", referenced from:
>>    TopLevel::setupKAction()      in toplevel.o
>> "KStandardGameAction::quit(QObject const*, char const*, QObject*)", referenced from:
>>    TopLevel::setupKAction()      in toplevel.o
>> ld: symbol(s) not found for architecture x86_64
>> collect2: ld returned 1 exit status
>> make[2]: *** [ktuberling/ktuberling.app/Contents/MacOS/ktuberling] Error 1
>> make[1]: *** [ktuberling/CMakeFiles/ktuberling.dir/all] Error 2
>> make[1]: *** Waiting for unfinished jobs….
> 
> The only reason I can think of for symbols being undefined, is those symbols not being there. You'll have to ask the makers of the library if the symbols are really there, and if they are, then ask the makers of the program you're trying to compile why it can't find the symbols.

Thanks for taking a look, Ryan.  Thanks to others for the discussion on
how to diagnose machine architecture.

The above errors also occur on games I have written myself.  Those symbols
are used by just about every KDE game.  They represent the standard menu
actions that replace the "File" menu in games and optionally provide actions
such as "Hint" or "Solve".  They HAVE to be on the KDE Games library.  They
have been there for more than 10 years and I have been building them into
my games on various machines, including Apple recently, for about that long.

Furthermore I can compile the above on my Linux machine and so can all
the members of the KDE Games developer group, including my Google
Summer of Code student in Brazil, who is new to KDE Games development
work.  A month ago I used to be able to build OK on my Macbook, now
I cannot.  What has changed?  Where should I look?

As I said before, I recently selfupdated to Macports 2.0.4.  Then I had that bug
where dbus would not start.  Then I had to re-build all of KDE libs and KDE
Games in order to add the +docs variant to KDE Games.  In the process, I
received more recent versions (4.8.x) of KDE libs and KDE Games, but
there may have been changes in other stuff, such as the compiler/linker,
cmake and make tools.

The full output from attempting to build the ktuberling game is attached.
Near the end of the file I have managed to get cmake and make to print
out the fully-expanded build command.  It uses /usr/bin/c++ to do the
link, and that evaluates as follows:

   Tara:/kdedev/build/kdegames>ll /usr/bin/c++
   lrwxr-xr-x  1 root  wheel  12 27 Dec 19:13 /usr/bin/c++@ -> llvm-g++-4.2

The same compiler is used to do the compile steps, as far as I can tell by
examining Makefiles.

I also attach a copy of the environment variables for my build.  The general
idea is that /kdedev/kdegames is the prefix for source code, /kdedev/build/kdegames
is the prefix for compilation and build output and /kdedev/kde4 ($KDEDIR)
is the prefix for installed code, library and data.

As you can see, the build command in the attached ktuberling.log is linking
to ../lib/libkdegames.6.0.0.dylib, which is the last compile and build of the
KDE Games library.  The following commands show that the library is
indeed 64-bit and does indeed contain the required symbols:

Tara:/kdedev/kdegames>file /kdedev/build/kdegames/lib/libkdegames.6.0.0.dylib/kdedev/build/kdegames/lib/libkdegames.6.0.0.dylib: Mach-O 64-bit dynamically linked shared library x86_64
Tara:/kdedev/kdegames>nm /kdedev/build/kdegames/lib/libkdegames.6.0.0.dylib | grep KStandardGameAction|egrep 'gameNew|load|save'
00000000000ada60 t __ZN19KStandardGameAction10loadRecentEPK7QObjectPKcPS0_
00000000000adac0 t __ZN19KStandardGameAction4loadEPK7QObjectPKcPS0_
00000000000ada00 t __ZN19KStandardGameAction4saveEPK7QObjectPKcPS0_
00000000000ad9a0 t __ZN19KStandardGameAction6saveAsEPK7QObjectPKcPS0_
00000000000adb20 t __ZN19KStandardGameAction7gameNewEPK7QObjectPKcPS0_

Just one thing: the symbols are listed with a small "t", which apparently means that
they are local, not external or exported, hence the linking problem.

In the source code, these symbols are all preceded by a KDEGAMES_EXPORT macro,
which should evaluate to something that will cause the symbol to be exported, but it
seems to be null (e.g. if I insert "int k =  KDEGAMES_EXPORT 42; ", it compiles).

From what I can tell, the definition of this macro somehow depends on whether the
compiler is GCC or Windows or neither (which makes it null).

Could the problem be that I have been previously compiling everything with
llvm-gcc-4.2, but now, since selfupdating to Macports 2.0.4,  llvm-g++-4.2 has got
into the picture?  If so, how can I get out of the difficulties I am in?  Perhaps I can
re-activate kdelibs4 @4.7.4_0 and switch back to llvm-gcc-4.2?

Hoping you can help, Ian W.


-------------- next part --------------
A non-text attachment was scrubbed...
Name: ktuberling.log
Type: application/octet-stream
Size: 5794 bytes
Desc: not available
URL: <http://lists.macosforge.org/pipermail/macports-users/attachments/20120518/b60ce71c/attachment.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: build.env
Type: application/octet-stream
Size: 1522 bytes
Desc: not available
URL: <http://lists.macosforge.org/pipermail/macports-users/attachments/20120518/b60ce71c/attachment-0001.obj>
-------------- next part --------------