#13 Trying to compile under Mac OS X 10.3

Game (10)


While probably millions of Linux and Windows users are happily
enjoying Attal, I'm unfortunately still on the compiling phase...

I run Mac OS X 10.3 with gcc 3.3 and QT3 (installed through fink),
and, of course, X11 (Apple version which comes with 10.3). Fink
uses a Debian-like package installation, so, seeing that Debian
Linux is supported, I tried to compile it...

After figuring out all the steps to install qt3 on the Mac, it seems
that all items are on their correct place. qmake properly finds out
the correct paths, and it's easy to fix when it "fails" to find
something (normally a few links to the proper directory structure
fix everything fine), so I get all Makefiles correctly. A surprise: it
seems that you can even add a -macx option to qmake, and qmake
will create fully-fledged Mac OS X applications (!). However, not
being too brave, I stuck with the -unix switch for now.

Unfortunately for me, compilation ends very soon, just with the
first library being compiled, libAttalCommon:

ld: Undefined symbols:
/usr/bin/libtool: internal link edit command failed

Ugh. Similar results occur in all libraries for THEME, IMAGE_PATH,
or SOUND_PATH. The reason seems to be in the way dynamic
libraries are handled under Mac OS X (or, rather, Darwin): gcc
needs the library to be "complete", it can't have external
references to things on other libraries (!).

I tried to put at least ONE of those without the "external" keyword,
and, sure, it compiles fine and creates the library as expected.
However, you need those libraries with external references, as I
understand that all those QStrings are defined on the applications
themselves (at least they're properly defined there).

All hell broke lose when I tried to compile libFight and got:

ld: Undefined symbols:
ChatWidget::ChatWidget[in-charge](QWidget*, char const*)
PopupUnit::PopupUnit[in-charge](QWidget*, char const*)
Icon::Icon[in-charge](QWidget*, char const*)
AskInt::AskInt[in-charge](QString, QWidget*, char const*)
ImageTheme::getCreature(unsigned, unsigned)
/usr/bin/libtool: internal link edit command failed
make[1]: *** [../libAttalFight.1.0.0.dylib] Error 1
make: *** [sub-libFight] Error 2

I presume that my problem has been in trying to declare at least a
few things on the "wrong" libraries, and after "pseudo-fixing" the
code, it came to a point when I got into declaration loops...

Has anyone tried to compile Attal under Mac OS X yet? Perhaps
there is an extra flag to qmake like "allow unresolved external
references". I've read TrollTech's manual for qmake, but didn't
have any luck.

One thing I did was to get static libraries instead of dynamic ones.
A few changes on the qmake.conf will do the trick, and they're not
hard to spot (starting with the "-dynamic" flag :) ). However, the
linker fails on exactly the same assumptions. So the problem is not
dynamic vs. static, but being able to build libraries with external
(unresolved) references or not.

Question: what can I do to change the code in order to get rid of
all those unresolved external references?


- Luis Sequeira


  • Nobody/Anonymous

    Logged In: NO

    Have you tried to compile attal with static libs?
    It should be #CONFIG += staticlib, decomment this in


  • Luis Miguel Sequeira

    Logged In: YES

    Excellent! Congratulations, your precious answer has worked! Seems that
    Mac OS X is really bad when dealing with dynamic libraries. Statically
    compiling the libs does wonders :) Everything compiles wonderfully
    without any tweaking (note: no SDL yet, but I'll try to figure it out
    later...), however, in my case, the applications were "installed" under the
    weird structure that Mac OS X uses.

    In any case, it's very easy to copy the relevant binaries to someplace
    else, say ~/Applications/attal, and put the "themes" under that same
    directory. Now I've just need to understand why I can make my first
    turn, but never the second... ah well... this should be easier to find out
    :-) :-) :-)

    Many, many thanks!

  • Luis Miguel Sequeira

    • status: open --> closed

Log in to post a comment.

Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:

JavaScript is required for this form.

No, thanks