> On Nov 3, 2016, at 17:26, Alexander Hansen <alexanderk.han...@gmail.com>
> wrote:
>
>>
>> On Nov 3, 2016, at 16:56, Hanspeter Niederstrasser <f...@snaggledworks.com
>> <mailto:f...@snaggledworks.com>> 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
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
