xephem seg faults on Mojave

[Richard L. Hamilton]

Well, the latest I found is that it does the same thing with an older build I had on El Capitan.  All the ports are current there too, because I update them all regularly.  None of the likely culprits have been updated recently, but xephem itself is the oldest there.

11:53:53[643]crabapple:/opt/local/bin> ls -lc /opt/local/bin/xephem /opt/local/lib/libXm.*.dylib /opt/local/lib/libXt.*.dylib
-rwxr-xr-x  1 root  admin  2289596 Dec 26  2016 /opt/local/bin/xephem
-rwxr-xr-x  1 root  admin  2837100 Jan  2  2018 /opt/local/lib/libXm.4.dylib
-rwxr-xr-x  1 root  admin   328232 Jan 24  2018 /opt/local/lib/libXt.6.dylib

That makes me think that it's something with openmotif or xorg-libXt that's messed up.  OTOH, other openmotif apps like nedit still work.  All other things being equal, it wouldn't surprise me if libXt is the culprit.  This error looks a lot like it did back when one had to link libXt with -flat-namespace if libXm was going to work with it (I think that's how it went), if one didn't do that.  

> On Oct 11, 2018, at 06:00, Richard L. Hamilton <rlhamil at smart.net> wrote:
> 
> The current version (3.7.7) is three years old, and apparently quite stable (I've run it on various macOS versions before).  The macOS binary from the originator works fine on Mojave.
> 
> Clearly he has his own build procedures (his binary is statically linked with all the required X11 and OpenMotif libraries, which certainly simplifies distribution), and doesn't use MacPorts, so whatever linkage issue (probably, IMO!) this is, he wouldn't encounter anyway.
> 
> 
>> On Oct 11, 2018, at 05:24, Chris Jones <jonesc at hep.phy.cam.ac.uk> wrote:
>> 
>> 
>> 
>> On 11/10/18 10:07, Richard L. Hamilton wrote:
>>> It doesn't have to be a bug with xephem (the code) at all, but with the build procedure, which apparently can have a lot of breakage going to Xcode 10.
>> 
>> Of course it could be that. My point was to not make assumptions, and start by contacting upstream.
>> 
> 
>