> 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 [email protected] and [email protected] ] > > > > This was reported as a bug to [email protected] 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 [email protected] http://cnswww.cns.cwru.edu/~chet/ > > _______________________________________________ Bug-readline mailing list [email protected] http://lists.gnu.org/mailman/listinfo/bug-readline
