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 <rlha...@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 <jon...@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. >> > >
