开云体育

compiles on xephem-4.1.0 have issues with XM when done with OSX 10.5.8 The compiler kicks the following errors with a make MOTIFI = ../../libXm/osx gcc -L../../libastro -L../../libip

I posted only a diff of my changes; ssl was already in the LIBS defn on line 37 so I did not have to change it.

with a make MOTIFI = ../../libXm/osx These were required for a successful build? on Mac OSX 10.5.8 for xephem version 4.0.1. With 4.1.0 I am somewhat mystified since you don't include a directive

Hi Karl, FYI, I fired up my old tower circa 2003(?) running 10.6.8 (Snow Leopard) and XQuartz 2.3.6. I downloaded 4.1.0 from https://github.com/XEphem/XEphem using code -> download zip. I unzipped

I think Trane and I are experiencing different issues and that is to be expected since we are compiling xephem on vastly different platforms. He is building on MODERN mac equipment probably using the

Hi, Brandon. Sorry for the delay in reply, but the IT streets has seen me rather busy today and I couldn't get into digging before now. I think I understand the scope of the issue now. All the

Yes, Trane .. I cheated my way past the libXp dependency by putting a copy of Print.h in the extensions folder, then struggled past the ssl issue by adding a path to CFLAGS and LDFLAGS to point at

Hi, Gavin. It appears that the removal of libXp dependency was only for Linux. For us to be able to compile on macOS against XQuartz later than 2.7.11, the libXp dependency also needs to be removed

In response to an earlier post by Brandon. I don't think the makefile is corrupted at least by me. To verify I unzipped and tried to compile a 4.1.0 version just now with the commenting out of the

With no wish to muddy the waters, I downloaded the `main` branch zip file referenced above and tried to build Xephem. ?I'm using macOS 12.1, the latest non-beta Xcode toolset and?XQuartz 2.8.1 on a

Thanks, everyone, for sharing your recent experiences on Mac! I'd like to make a better Mac compilation experience a focus for the next XEphem release. *Karl Oestreich* — I will be interested to

Karl, Regarding your display error, you might want to try starting XEphem via a script saved as an application object. I've been using this for years. It is utterly reliable and enables one to have

I wound up taking all the Makefiles from 4.0.1 and copying them into 4.1, e.g., from the root of the 4.0.1 source folder: for file in $(find . -name "Makefile" -print); do ? cp $file

xephem-4.0.2 compiles but when executed kicks the couldn't find per display information? error... I think I have seen some rumblings in the forum about this "glitch" xephem-4.0.1 again compiles but

xephem-4.0.1 compiles??????? I did it just now?? xephem-4.1.0 does not, still hung up with some ssl library foolishness

slightly better results make[1]: `libz.a' is up to date. gcc -L../../libastro -L../../libip -L../../liblilxml -L../../libjpegd -L../../libpng -L../../libz -g -L/usr/lib -L/opt/local/lib -o xephem

Argh. Proofread, boy! Line 38, not 37. LIBS = $(XLIBS) $(LIBLIB) -lm -lssl // // Trane Francks trane@... Tokyo, Japan // Practice random kindness and senseless acts of beauty.

After replacing all the Makefiles from 4.0.1 in 4.1, I've managed to get 4.1 to compile on macOS Big Sur by adding switch "-lssl" at line 37 of Makefile in GUI/xephem. Brandon, I'm not sure where,

Hi, Karl. Try compiling the v4.0.1 source. That Makefile seems to be intact. Per Elwood's previous suggestions, you may want to remove the __APPLE__ hack from xephem.c (lines 148-161, I think it is).

If that's really your entire link line you are missing a zillion more files. Look in the Makefile for fsmenu.o and you will see many more files after that which define all the symbols you are missing.