Re: [Bug-readline] Re: problem installing ppsp on Intel Mac

[John Pollock]

> Not sure who originally had this problem, but someone has created a Mac
> OS X package that uses the X11 libraries, and psppire works just dandy
> (at least on 10.5.7).  Not completely Mac-like, since you must open
> files from within psppire, rather than double-clicking them, but it
> works.  You could probably write a shell script to handle the
> double-clicking part, if you are so inclined.

I was the one with the issue, and unfortunately the machine in question is
running OS X 10.4, which isn't supported by the version of PSPP you
mention.

I spent a long time doing everything imaginable to get the "Evolution
Beach" prebuilt version of PSPP to work, but I was never able to get past
the problem where PSPP looks at libraries in /usr/lib instead of
/opt/local/lib, and thus finds the wrong version of libiconv.2.dylib.  I
tried setting DYLD_LIBRARY_PATH and LD_LIBRARY_PATH in .cshrc as well as
in /opt/local/bin/ppsp, but nothing worked; it kept looking in the wrong
place.  I couldn't tell if this is an issue with OS X or with the way the
pspp binary was compiled, but I wasn't able to fix it.

As to Chet's suggestion of linking to a static version of the library, I
haven't been able to try that I decided to install a fresh copy of
Macports after blowing away /opt/local, and that has been my undoing.
After the reinstall of Macports, the reinstall of pspp bombed out during
the staging of atk due to the error "gtkdoc-rebase: command not found".
The error appears to have been the result of a race condition because it
didn't repeat on a re-run, but then gtk failed to build due to an invalid
generated cache as reported by gtk-update-icon-cache.  I haven't yet been
able to get past this last error.

Cheers,
John


On Thu, 10 Sep 2009, Chet Ramey wrote:

> John Darrington wrote:
> > [ Cross posting to address@hidden and address@hidden ]
> >
> > This was reported as a bug to address@hidden some weeks ago.  However,
> > the readline maintainer said that there was a reason for this:
> > http://lists.gnu.org/archive/html/bug-readline/2009-06/msg00000.html
> >
> > I must admit, I didn't quite follow the logic. Perhaps somebody more
> > familiar with readline could explain how to resolve this.
>
> Readline is GNU software, and, as such, uses xmalloc/xfree/xrealloc to do
> its memory allocation with the usual GNU semantics.  Since those functions
> are global, they're exported by the library and available for applications
> using readline to use.
>
> Traditional Unix linker semantics, even in the presence of shared
> libraries, allow applications and other libraries to override (shadow)
> symbol definitions.  This allows, for example, bash to provide its own
> implementation of getenv() that looks in the shell's table of exported
> variables instead of the initial shell environment.
>
> The basic idea is that the linker keeps a list of unresolved symbols
> as it processes libraries, beginning to end as they're specified on
> the command line, and doesn't link in already-resolved symbols from
> libraries on a per-file basis.
>
> It's often desirable, and in some cases required, that applications unify
> their memory allocation in one set of functions.  To accommodate this,
> Readline uses public functions to do its memory allocation, which, using
> the traditional Unix linker semantics, allows an application to provide
> its own definitions of xmalloc/xrealloc/xfree and have Readline use them.
> Readline provides its own definitions in case the application does not.
>
> It seems that Mac OS X, with its peculiar shared library semantics, has
> broken this.  You might try linking against a static version of the
> readline library, if you have one installed in /opt/local/lib.
>
> Chet
> --
> ``The lyf so short, the craft so long to lerne.'' - Chaucer
>                ``Ars longa, vita brevis'' - Hippocrates
> Chet Ramey, ITS, CWRU    address@hidden    http://cnswww.cns.cwru.edu/~chet/
>
>