[Wesnoth-dev] static build on Mac OS X?

[ott]

Some comments about building BfW on Mac OS X, and more specifically a
query on building a static binary for Mac OS X.

Sithrandel has for a long time been making builds with a Cocoa wrapper.
This build creates an application bundle consisting of a dynamically
linked binary, as well as copies of all the shared libraries which it
is linked against.  This includes the SDL libraries as well as libraries
to support internationalization.  In addition, this bundle also carries
a copy of all the shared data files.  This bundle is reasonable, but
it has the big disadvantage that it constitutes a fork of the code:
the Cocoa wrapper adds additional functionality which other versions of
the game do not have, such as the processing of zipped campaigns dropped
onto the application, and the scenario editor.  With Sithrandel's build
there is also a non-standard map editor as part of the scenario editor.
Since the bundle carries the game data, and there is no standard location
where it can end up, there is no obvious way for the standard Map Editor
to access those files.

In an effort to allow BfW to be integrated into automatic build
systems like fink, I have been making sure the usual configure/make
commandline build process works on Mac OS X.  This process relies
on the shared game data residing in the usual $prefix/share/wesnoth/
location.  In addition, the makefile target wesnoth_bundle also creates
a barebones Mac OS X application that can be launched from the Finder,
and wesnoth_editor_bundle creates a corresponding standard Map Editor
application.  Obviously wesnoth_bundle is not as fully featured as
Sithrandel's build, but it has the advantage that it is virtually
identical to the build for every other platform.

Recently, crimson_penguin released a build of 0.9.2 which has highlighted
a problem: the version of libstdc++ appears to have changed in Mac
OS X 10.3.9.  This means that we most likely need to link statically
against libstdc++.a instead of relying on /usr/lib/libstdc++.6.dylib to
be present on the system.  For more details, see the forum.

Currently, the --enable-static option of configure simply prefaces the
usual 'g++ -o wesnoth *.o' with 'libtool --mode=link'.  This is clearly
not going to work on Mac OS X: the system default libtool is intended
to create static or dynamic libraries, not executables.  If we replace
'libtool' with 'glibtool' on Mac OS X, relying on the fink-provided
glibtool (which is just a standard GNU libtool), then --mode=-link
simply calls g++ as before and produces a dynamically linked binary.
This is not sufficient to create a statically linked binary.

I investigated building a binary which is statically linked against
all libraries that could cause problems, and this appears feasible.
My commandline looks something like (reformatted for clarity and with
all -L/-l shortcuts expanded in full):

glibtool --mode=link --tag=CXX
g++ -o wesnoth <long list of .o files>
/sw/lib/libSDL_image.a /sw/lib/libSDL_mixer.a /sw/lib/libSDL_net.a
/sw/lib/libSDLmain.a /sw/lib/libSDL.a
-framework Carbon -framework Cocoa -framework OpenGL -framework CoreFoundation
-framework IOKit -framework AudioUnit -framework QuickTime
/sw/lib/freetype219/lib/libfreetype.a /sw/lib/libintl.a
/usr/lib/libiconv.dylib /usr/lib/libz.dylib
/sw/lib/libpng.a /sw/lib/libjpeg.a /sw/lib/libmikmod.a /sw/lib/libsmpeg.a
/sw/lib/libvorbisfile.a /sw/lib/libvorbis.a /sw/lib/libogg.a

Note the absence of references to libX11.*; this library doesn't seem to
be necessary for this build.  The various /sw/lib libraries are from fink,
the /usr/lib ones are provided by the system, as are the frameworks.
This command simply calls g++, the 'glibtool --mode=link --tag=CXX'
part doesn't seem to modify the actual link phase at all.

How to actually get (g)libtool to change the various .dylib library
references to instead use the .a versions, I don't know.

This produces a 6MB stripped binary, about which otool -L (roughly
equivalent to ldd) says:

wesnoth:
        /System/Library/Frameworks/Carbon.framework/Versions/A/Carbon 
(compatibility version 2.0.0, current version 128.0.0)
        /System/Library/Frameworks/Cocoa.framework/Versions/A/Cocoa 
(compatibility version 1.0.0, current version 9.0.0)
        /System/Library/Frameworks/OpenGL.framework/Versions/A/OpenGL 
(compatibility version 1.0.0, current version 1.0.0)
        /usr/lib/libiconv.2.dylib (compatibility version 5.0.0, current version 
5.0.0)
        
/System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation 
(compatibility version 150.0.0, current version 299.35.0)
        /System/Library/Frameworks/IOKit.framework/Versions/A/IOKit 
(compatibility version 1.0.0, current version 184.0.0)
        /usr/lib/libz.1.dylib (compatibility version 1.0.0, current version 
1.0.0)
        /System/Library/Frameworks/AudioUnit.framework/Versions/A/AudioUnit 
(compatibility version 1.0.0, current version 1.0.0)
        /System/Library/Frameworks/QuickTime.framework/Versions/A/QuickTime 
(compatibility version 1.0.0, current version 11.0.0)
        /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current 
version 71.1.3)

All of these should be present on Mac OS X, at least the various 10.3.x
releases.

Does anyone know how we could integrate static builds into the
configure/make process, specifically for Mac OS X, but possibly also
for other platforms?

-- address@hidden