Re: [Adonthell-devel] compiling v0.4 on OS X

[Kai Sterker]

Am Dienstag, 22.07.03 um 11:17 Uhr schrieb Alexandre Courbot:

> Ah, right. Actually - have you noticed? It tries to load a .a library 
> (a
> static one!) while it shoud load a .so. Can you look into 
> src/gfx/.libs/
> whether there is a sdl.so file?

Nope, there's none. (Although on OS X it would be called sdl.dylib).

> If it doesn't, we just need to ask libtool to
> make shared libraries. Shouldn't be a big deal. Unless your compilation
> toolchain doesn't support shared libs? Can you check whether the 
> binaries are
> shared with ldd?

No ldd on OS X, sorry. With libtool 1.5, shared libraries should be no 
problem. At least that is what the libtool manual says.


> > There are some issues with libtool left. That does not break the
> > compilation, but it might have caused the trouble with the libraries. 
> > I
> > will investigate this further today.
>
> Can you elaborate on these issues? They might be linked.

Apart from a few bugs in libtool 1.5 (SED, EGREP and max_cmd_len 
undefined) there is an issue with linking in some libraries. I.e. they 
only exist as static version, which leads to the following message:

*** Warning: linker path does not have real file for library 
-lpython2.2.
*** I have the capability to make that library automatically link in 
when
*** you link to this library.  But I can only do this if you have a
*** shared version of the library, which you do not appear to have
*** because I did check the linker path looking for a file starting
*** with libpython2.2 and none of the candidates passed a file format 
test
*** using a file magic. Last file checked: 
/usr/lib/python2.2/config/libpython2.2.a

*** Warning: libtool could not satisfy all declared inter-library
*** dependencies of module _gfx.  Therefore, libtool will create
*** a static module, that should work as long as the dlopening
*** application is linked with the -dlopen flag.

Other such libs are libstdc++ and libSDLmain. For some reason, there 
are no dynamic versions of those.

Maybe something can be done with the -dlopen flag. I tried adding this 
to the inputtest target, but on compilation I got:

/bin/sh ../libtool --mode=link g++  -g -Wall -fno-exceptions -fno-rtti 
-I../src/   -o inputtest  inputtest.o -dlopen -L../src/gfx/ 
-ladonthell_gfx -L../src/input/ -ladonthell_input -lz
libtool: link: warning: `AC_LIBTOOL_DLOPEN' not used. Assuming no 
dlopen support.

Maybe you can make something of this. I'll be out shopping now, but 
I'll do some tests myself in the afternoon.

Kai