Since I don’t plan to do all of this myself (or possibly at all), and because I
am completely fed up with people sending me direct emails about packages that I
don’t own, forwarding on.
> Begin forwarded message:
>
> From: Jack Howarth <howarth.at.f...@gmail.com>
> Subject: Re: [Fink-devel] Apparently libXt isn't actually a leaf on the X11
> library tree after all
> Date: November 2, 2016 at 18:43:47 PDT
> To: Alexander Hansen <alexanderk.han...@gmail.com>
>
>
>
> On Wed, Nov 2, 2016 at 7:48 PM, Alexander Hansen <alexanderk.han...@gmail.com
> <mailto: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.
>
>
> For the near term, option 2 certainly sounds like the best approach. We will
> have to build our way of the current mess to eliminate linkages on
> libxt-shlibs as those may have other subtle destabilizations that we haven't
> noticed yet. Also libxt puts the onus on the package maintainers to avoid
> non-deterministic builds.
>
> As for libxt-flat, it should be replaced with a buried copy like what I
> originally proposed. The universe of software that uses motif is small and
> isn't going to get any larger so it is very manageable to deal with. Sadly
> all of the packages which were updated in the last week will have to be
> redone.
>
> 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