pspp-users
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Building PSPP on a Mac


From: Ben Pfaff
Subject: Re: Building PSPP on a Mac
Date: Mon, 13 Oct 2008 18:06:22 -0700
User-agent: Gnus/5.11 (Gnus v5.11) Emacs/22.2 (gnu/linux)

Richard Brittain <address@hidden> writes:

> On Sat, 11 Oct 2008, Ben Pfaff wrote:
>>> 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.

That's helpful, thanks.

For now, I've filed a bug report with these facts.  It's bug
#24553 at Savannah.  You should receive a separate email about
it, since I took the liberty of CC'ing you on the bug report.

>>> 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()

I'm starting to think that this and some of the other odd
behavior we've seen on Mac and Windows may have to do with the
relatively old version of libtool that I used to generate the
PSPP tarballs.  As an experiment, I've re-built a PSPP 0.6.1
tarball using libtool 2.2.2, which is much newer.  If you are
willing and able, please try out the following tarball and let me
know whether the results are better or worse:
        ftp://alpha.gnu.org/gnu/pspp/pspp-0.6.1+libtool-2.2.2.tar.gz
(Note that this will extract into a directory named pspp-0.6.1,
since really it *is* pspp-0.6.1, just assembled slightly
differently).
-- 
"I was born lazy.  I am no lazier now than I was forty years ago, 
 but that is because I reached the limit forty years ago.  You can't 
 go beyond possibility."
--Mark Twain




reply via email to

[Prev in Thread] Current Thread [Next in Thread]