Building Wx with ActivePerl on Mac OSX

Ensure you have the prerequisite modules installed using PPM first.

These instructions are for building portable binaries on MacOSX for ActivePerl. The information may be useful in other situations, such as building generally portable binaries, but it is primarily a description of the build process used for the PPM's at this site.

The builds of ActivePerl for MacOSX target version 10.4 and above. This makes the choice of which versions of MacOSX to support for binary builds straightforward. You would not wish to provide PPMs that did not work for Tiger 10.4 and you cannot build for anything earlier. The PPMs for this site are built on an Intel machine running Snow Leopard and tested for distribution and packaged PDK operation on a ppc G4 machine running Tiger.

To build Alien::wxWidgets, Wx and Wx xs modules on MacOSX and ActivePerl, you need to install ExtUtils::FakeConfig. You can do this either by building from CPAN yourself, or you can install using the Perl Package Manager. Note that the PPM install option applies only to MacOSX. On MS Windows you MUST install from the cpan shell or build the downloaded source yourself.

Once ExtUtils::FakeConfig is installed, you need to download and place  Config_osx.pm  somewhere in your @INC path.

The build command for Alien::wxWidgets is:

perl Build.PL --wxWidgets-extraflags="CC=gcc-4.0 CXX=g++-4.0 LD=g++-4.0 --enable-universal_binary --enable-graphics_ctx --with-opengl --disable-compat26 --enable-mediactrl --with-libjpeg=builtin --with-libpng=builtin --with-regex=builtin --with-libtiff=builtin --with-zlib=builtin --with-expat=builtin --with-libxpm=builtin --with-macosx-sdk=/Developer/SDKs/MacOSX10.4u.sdk --with-macosx-version-min=10.4" --wxWidgets-build='yes' --wxWidgets-source='tar.gz' --wxWidgets-unicode=1 --wxWidgets-build-opengl=1 --wxWidgets-version=2.8.10 --wxWidgets-universal

perl Build

perl Build test

perl Build install

Some of this may not be needed but it is directly from the script used to build the PPMs at this site.

One other note is that as the PPMs are built on Snow Leopard, the build environment is set up using the following:

export CC=gcc-4.0

export CXX=g++-4.0

export LD=g++-4.0

This probably is not necessary as it should be taken care of by the wxWidgets-extraflags options when building Alien-wxWidgets, and by Config_osx when building any other modules.

Building Wx (and other Wx related xs modules) is then:

perl -MConfig_osx Makefile.PL

make

make test

make install

You may wish to add Config_osx to your environment with 

export PERL5OPT=-MConfig_osx 

but once again, as that is not what is currently done in my build scripts, I have not noted it as a proven working option. I cannot see why it would not work though.

Quite a major change is made to the wxWidgets dynamic libraries for packaging within a PPM. The location of the installed wxWidgets libraries is hard coded into the Wx xs modules and the wxWidgets libraries themselves  when they are built. This is not suitable for PPMs where the install location will almost certainly change nor is it generally suitable for the available packaging methods for perl applications. 

OSX has DYLD_LIBRARY_PATH which is similar to LD_LIBRARY_PATH on Linux, but like LD_LIBRARY_PATH it needs to be set before your executable starts. MacOSX app bundles can set a DYLD_LIBRARY_PATH in their configuration files which would have worked for PPM distribution but this is not supported 'out of the box' by the available application packagers.

The method used to support a relocatable Wx is to encode the path of all .bundle and .dylib files as relative to the executable. On MacOSX the true wxPerl executable (perl) is at  

../auto/Wx/wxPerl.app/Contents/MacOS/wxPerl.  

By placing the wxWidgets dylibs at 

../auto/Wx/wxPerl.app/Contents/Frameworks/filename.dylib 

it is possible to encode the location as relative to the executable. As the layout for an app bundle is standard, this means that the libraries also work in the same way when packaged up with a perl application packager. So on MacOSX, the PPM for Wx is self contained. There is no PPM for Alien-wxWIdgets.  

Relocation is done using the xcode tool install_name_tool. All of the .bundle files (xs modules) in the distribution have to be relocated in this way in addition to the wxWidgets libraries. When building other xs modules such as Wx::TreeListCtrl, those .bundle files must be relocated too.

When built at the command line, Wx installs a copy of the local Perl executable into the wxPerl.app bundle. We can't distribute this within a PPM so the PPM calls an install script which installs a copy of the local perl executable.

The easiest way to explain the detail of all this is to enclose a snippet of the MacOSX build script. It was put together in a short time so is fairly ugly - but it does show the steps followed.

One final change is made to the standard distribution of Wx. Normally, Wx will install a 'wxPerl' executable in your 'site/bin' directory that you use to run Wx scripts. Some paths in this are hard coded because that's a simple and 100% reliable method if you are building just for the target machine. For PPMs an amended executable is installed that attempts to locate the Wx installation relative to its own location. This works in all tests run so far.