Daniel,
I am seeing...
$ xemacs
Error: Couldn't find per display information
for
ii xemacs 21.4.22-8 Highly customizable text editor
ii libxaw3dxft 1.6.2-6 Athena widget set with 3D look
ii libxaw3dxft-sh 1.6.2-6 Athena widget set with 3D look
ii libxt 1.1.5-2 X toolkit library
ii libxt-flat-shl 1.1.5-2 X toolkit library
ii libxt-shlibs 1.1.5-2 X toolkit library
under Xquartz 2.7.11 despite the back port the Debian fix for
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=327655.
The only thing that solves the issue here on 10.11 is to link both
libxaw3dxft and xemacs against the libXt from Xquartz.
Jack
On Wed, Nov 2, 2016 at 7:48 PM, Alexander Hansen <
alexanderk.han...@gmail.com> wrote:
> We had thought that libXt wasn’t actually linked in the X11 tree, but this
> appears not to be so.
>
> It’s linked by:
> /opt/X11/lib/libXaw6.6.dylib
> /opt/X11/lib/libXaw7.7.dylib:
> /opt/X11/lib/libXaw8.8.dylib:
> /opt/X11/lib/libXaw3d.8.dylib:
> (these may not matter since we’ve got libxaw3dxft2)
> /opt/X11/lib/libxkbui.1.dylib
> /opt/X11/lib/libXmu.6.dylib
>
> The last one appears to be what is causing runtime failures with xemacs,
> since xemacs links to /opt/X11/lib/libXmu.6.dylib and to
> /opt/X11/lib/libXt.6.dylib, along with our libXaw.8.dylib
> (libxaw3dxft-shlibs) which now links to Fink’s libxt.6.dylib from
> libxt-shlibs.
>
> Unfortunately, the whole rationale for having our own libxt (not so much
> for libxt-flat) was to try to provide a consistent libXt so that people
> wouldn’t have things break when updating from Xquartz 2.7.8 to later
> versions where libXt has been mucked with.
>
> Here are some options:
>
> 1) Ditch libxt, possibly libxt-flat, and roll our own Xquartz
> 2) Ditch libxt, and force people to install Xquartz-2.7.11. Right now
> we’d have to use the “system-pkgconfig-xorg-server” virtual package to do
> this. In principle we could adjust system-xfree86* to get the aggregate
> Xquartz release version instead of the “2:7.2” that we’ve been using for
> ages, but I don’t know if that gets stored anywhere but the package
> receipt, and that’s somewhat fragile to rely on.
>
> We’d want to adjust the fink-package-precedence script appropriately for
> whichever option we pick.
>
> #2 seems like the least work in the short term, but I know that some folks
> in the community don’t like it when we force dependencies on particular
> versions of non-Fink tools (e.g. the Xcode CL tools).
> #1 would rely on some kind soul being willing/able to maintain a Fink
> Xquartz, and we’d have to modify our existing X11-using packages to use
> only a Fink Xquartz.
>
> Though I’m leaning towards the following options:
>
> 3) Stop bothering with X11 packages
> 4) Give the hell up
> --
> Alexander Hansen, Ph.D.
> Fink User Liaison
>
>
> ------------------------------------------------------------
> ------------------
> Developer Access Program for Intel Xeon Phi Processors
> Access to Intel Xeon Phi processor-based developer platforms.
> With one year of Intel Parallel Studio XE.
> Training and support from Colfax.
> Order your platform today. http://sdm.link/xeonphi
> _______________________________________________
> Fink-devel mailing list
> Fink-devel@lists.sourceforge.net
> List archive:
> http://news.gmane.org/gmane.os.apple.fink.devel
> Subscription management:
> https://lists.sourceforge.net/lists/listinfo/fink-devel
>
------------------------------------------------------------------------------
Developer Access Program for Intel Xeon Phi Processors
Access to Intel Xeon Phi processor-based developer platforms.
With one year of Intel Parallel Studio XE.
Training and support from Colfax.
Order your platform today. http://sdm.link/xeonphi
_______________________________________________
Fink-devel mailing list
Fink-devel@lists.sourceforge.net
List archive:
http://news.gmane.org/gmane.os.apple.fink.devel
Subscription management:
https://lists.sourceforge.net/lists/listinfo/fink-devel
