Re: Apparently libXt isn't actually a leaf on the X11 library tree after all
Alexander Hansen <[email protected]>
| Newsgroups | gmane.os.apple.fink.devel |
|---|---|
| Message-ID | <[email protected]> |
> On Nov 3, 2016, at 17:26, Alexander Hansen <[email protected]> wrote: > >> >> On Nov 3, 2016, at 16:56, Hanspeter Niederstrasser <[email protected] <mailto:[email protected]>> wrote: >> >> On 11/2/16 6:48 PM, Alexander Hansen 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 >> >> I've been keeping an X11 set of packages mostly up to date: >> http://cvs.snaggledworks.com/viewvc.cgi/fink/10.7/main/finkinfo/x11 <http://cvs.snaggledworks.com/viewvc.cgi/fink/10.7/main/finkinfo/x11> and >> x11-system directories. >> >> The libraries are current. xorg-server is not current and I haven't used >> it in probably 3 years (and I was running 10.7 at the time). Although it >> ran, there were several things that still needed patching (xinit I >> believe was looking in wrong paths). Also, IIRC, StartupItems behavior >> has changed since then and would probably need to be fixed in these >> packages. Also, there currently is no xorg-libxt-flat package in my set. >> >> I'm agnostic on rolling our own versus forcing an update to 2.7.11. The >> latter is less work, but we are at the mercy of another fix from upstream. >> >> Hanspeter >> >> > > Personally, I don’t see much point in not just dealing with what Xquartz throws at us. We didn’t elect to use our own X11 distro at the time 10.5 came out, so trying to do that now seems like a huge hassle if it is installed in the Fink tree. Installing outside of the Fink tree will also be a hassle unless we use /opt/X11, and then we get into the alternative hassle of dealing with manual overwrites. > > --akh Here’s my proposal: 1) Merge a feature branch I created—this uses the Xquartz version in the system-xfree86* packages instead of always “2:7.2-2”. https://github.com/fink/fink/tree/show-xquartz-release-version 2) Update libxaw3dxft and packages which depend on it to carry: BuildConflicts: libxt, libxt-flat as well as *Depends on system-xfree86{-shlibs,-dev} (>= 3:2.7.112-3). (The versioning that I can extract from the Xquartz receipt gives 2.7.112 for Xquartz-2.7.11). 3) Get rid of libxt (not flat). I guess as an alternative we could just have _it_ carry the system-xfree86 dependency and relegate it to a bundle which installs no files. I’m not currently worried about libxt-flat and Motif-related packages because they work right now. -- 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 [email protected] List archive: http://news.gmane.org/gmane.os.apple.fink.devel Subscription management: https://lists.sourceforge.net/lists/listinfo/fink-devel