Re: Building PSPP on a Mac

[Richard Brittain]

On Sat, 11 Oct 2008, Ben Pfaff wrote:

> Hello.  Thanks so much for the detailed notes.
>
> > 4. Make sure the ports package is updated, and install all the
> > prerequisite libraries for PSPP
> >
> > sudo port selfupdate
> > sudo port install yelp gsl plotutils
> >
> > This will run for _hours_, downloading sources from BSD ports
> > repositories and compiling and installing them.  It will automatically
> > pull down all needed prerequisite packages.  On my system I ended
> > up with 94 port packages installed.  You can use "port list installed"
> > to see them.  All of the prerequisites are supported ports.  Some
> > of the packages are just newer versions of things which the Mac has
> > already, like perl and python.
>
> Wow.  I am not familiar with OS X, but I am surprised that binary
> packages are not available for these programs.  There is little
> benefit in compiling them for yourself if you can install binaries.

I believe that there are binary packages available through MacPorts, but 
the default behaviour is to build from source, and I wanted to do as 
little non-default stuff as possible at this step.  The dependencies seem 
to err on the side of safety, and it spends a lot of time doing things 
other than compiling.  I know that many of the packages can be obtained 
precompiled from other sources, but the ports mechanism ensures that the 
whole lot is self consistent.

> > 6. In a terminal, cd to the unpacked psp source tree and run configure
> >
> > ./configure CPPFLAGS="/opt/local/include" LDFLAGS="-L/opt/local/lib 
> > -L/usr/local/lib/pspp"
>
> Probably there's a missing -I in those CPPFLAGS but otherwise it
> looks right.

Oops - typo.

> > I get 1 failing test in the set of 158.  The actual message is:
> > 1c1
> > < /private/tmp/pspp-tst-8859/foo.sps:10: error: DISPLAY: AKSDJ is not a 
> > variable name.
> > ---
> > > /tmp/pspp-tst-8859/foo.sps:10: error: DISPLAY: AKSDJ is not a variable name.
>
> How unusual.  Is there actually a /private directory on your
> system, and does it have some relationship to /tmp?

On OSX, /tmp symlinks to /private/tmp - I think it is just to make it 
easier to stop the finder from browsing down that tree too easily.  I 
presume that the other tests also write files in /tmp, so that in itself 
isn't causing the problem.

> > 10.  Make symlinks for libpsppire.so and libpsppwidgets.so
> >
> > The dynamic library routines seem to be hard coded to look for .so
> > files, but on the Mac they are called .dylib files, which seem to be
> > equivalent.
> >
> > cd /usr/local/lib/pspp
> > sudo ln -s libpspsswidgets.dylib libpsppwidgets.so
> > sudo ln -s libpsppire.dylib libpsppire.so
>
> Hmm.  There is certainly nothing hard-coded into our source tree
> with the .so extension.  I don't know why this would be happening.

The actual error came from libglade.  My guess is that a UI item created 
by Glade was causing it to dynamically load a library not previously used, 
and libglade was searching for libpsppire.so with dlopen()

> > 12. Set $DYLD_LIBRARY_PATH
> >
> > Set $DYLD_LIBRARY_PATH to allow the dynamic link loader to find the
> > psppire and psppwidgets libaries.
> >
> > export DYLD_LIBRARY_PATH=/usr/local/lib/pspp
> >
> > This can be added to ~/.bashrc so that it always takes effect, or
> > there could be a simple wrapper script to start up psppire which sets
> > $DYLD_LIBRARY_PATH first.  I'm not sure why this is needed for
> > /usr/local/lib/pspp and not for /opt/local/lib.
>
> You should be able to add something to LDFLAGS to bypass this
> step.  On GNU/Linux, the option would be something like
> LDFLAGS="-Wl,-rpath,/usr/local/lib".

I suspect that this is true.  I'd already learned more than I wanted to 
know about dynamic linking on OSX so I stopped with the first solution 
that worked!

> > I've not yet figured out how to get other than  ASCII output from psppire,
> > or generate plots and charts.
>
> That's something that's not really present in the current version
> of PSPPIRE, but it's a pretty high priority for the next
> version.

Aha - I look forward to it :-)
Our statistics guy reckons that most of the potential users have got out 
of the command-line habit since SPSS effectively took it away (we don't 
run the SPSS server version here).

Richard
--
Richard Brittain,  Kiewit Computing Services, 6224 Baker/Berry Library
                   Dartmouth College, Hanover NH 03755
Email: address@hidden