FWIW re "Apple has deprecated a whole bunch of things with Mojave and later. Including Open GL Open CL."
<https://www.phoronix.com/scan.php?page=news_item&px=GTK4-macOS-Improved <https://www.phoronix.com/scan.php?page=news_item&px=GTK4-macOS-Improved>> "GTK4 is bringing with it a new macOS back-end that helps improve the performance. The new macOS back-end supports software-based rendering via Cairo or GPU-accelerated rendering by means of OpenGL. Yes, OpenGL is deprecated on macOS but does remain available with macOS 11.0 Big Sur. There isn't yet any Apple Metal or Vulkan-on-MoltenVK support for the macOS back-end with GTK 4.0." My emphasis with BU > On Mar 21, 2021, at 1:11 PM, Peter Teeson <peter.tee...@me.com> wrote: > > Jürgen you are clearly a 10th degree black belt when it comes to the GNU > build system, > At one point I did dig into the relationships and functions of the autotools. > But I am too old a dog beyond basic understanding. Xcode is just as complex > btw but it does have a nice GUI. > > Your explanation below is truly educational in a beautifully terse text. And > I am grateful for your time and patience. > > From a pragmatic POV John & I only discovered the dependancies after we had > built apl and got the SYNTAX error. > Admittedly the ./configure log did flag the missing libs and that resulted in > a non-functional ⎕PLOT. > > Neither of us knew to check for that. Perhaps a Warning echo could be > helpful? > Now we know, thanks to your lucid explanation. > > This thread is going to be saved for inclusion, as an appendix, in version > 2.0 of “A Brief Installation Guide” > > Lastly I am going to check GTK 3 and X11 support for Apple’s metal graphics. > Apple has deprecated a whole bunch of things with Mojave and later. Including > Open GL Open CL. > <https://developer.apple.com/documentation/macos-release-notes/macos-mojave-10_14-release-notes > > <https://developer.apple.com/documentation/macos-release-notes/macos-mojave-10_14-release-notes>> > <https://developer.apple.com/metal/ <https://developer.apple.com/metal/>> > > It crystal clear that Apple is moving to it’s own silicon over the next 2 > years. Gives them ironclad control of everything. > So 3rd party SW does it their way or not at all. I suspect that at some point > they might not permit non-Apple libs. > Maybe I’m too pessimistic - but platform control is their long established > DNA. > > respect > > Peter > > >> On Mar 21, 2021, at 7:30 AM, Dr. Jürgen Sauermann >> <m...@xn--jrgen-sauermann-zvb.de <mailto:m...@xn--jrgen-sauermann-zvb.de>> >> wrote: >> >> Hi Peter, >> >> 1. most ⎕-functions have no dependencies. All remaining dependencies >> are (ideally) determined by ./configue. The result of that is stored in >> config.h by ./configure and you can easily check it with: >> >> grep HAVE_ config.h >> >> in the top-level directory (and after ./configure). >> >> 2. To see who cares for what you can then: >> >> grep HAVE_ src/*hh src/*cc >> >> 3. of all HAVE_ macroa shown, only the following ones are related >> to ⎕-functions in some way: >> >> src/Quad_RVAL.hh:#if HAVE_LIBC >> src/Quad_RE.hh:#ifdef HAVE_LIBPCRE2_32 >> src/Plot_xcb.cc <http://plot_xcb.cc/>:#if HAVE_LIBX11 && HAVE_LIBXCB && >> HAVE_LIBX11_XCB && HAVE_X11_XLIB_XCB_H >> src/Quad_FFT.cc <http://quad_fft.cc/>:#if defined(HAVE_LIBFFTW3) && >> defined(HAVE_FFTW3_H) >> src/Quad_PLOT.cc <http://quad_plot.cc/>:# if defined( HAVE_LIBX11 ) >> src/Quad_PLOT.cc <http://quad_plot.cc/>:# if defined( HAVE_LIBXCB ) >> src/Quad_PLOT.cc <http://quad_plot.cc/>:#i >> src/Quad_RE.cc <http://quad_re.cc/>:#if HAVE_LIBPCRE2_32 >> >> which boils down to ⎕RVAL, ⎕RE, ⎕FFT, and ⎕PLOT being dependent on >> additional libraries, >> >> 4. Not all libraries are always needed, though. For example: >> >> ⎕PLOT can switch between GTK3 and XCB and then uses the better (= GTK3) of >> them, >> ⎕SQL adapts itself to different SQL providers SQLITE3 and POSTGRES and then >> uses all of them, >> >> The HAVE_ macros are not only used to control the behaviour of ⎕-functions >> but to deal >> with platform differences in general. Forr that reason there are more HAVE_ >> macros than >> optional libraries. >> >> 5. The ./configure script not only #defines or #undefs the HAVE_ macros in >> config.h but >> also manipulates the compiler and linker flags in the various Makefiles. So >> that at the end >> of the day only existing librariees and header files are being used in the >> build process. >> >> 6. The test for libraries and header files themselves are located in either >> configure.ac (from >> which ./configure is created) or in one of the m4/*.m4 files (which are all >> included by configure.ac). >> The test are the point where the build preferences of the user are combined >> with the existing >> libraries. A well-supported library comes with a .m4 file that checks its >> installation. Most of the >> autoconf magic happens here, the rest above is only the results of the magic. >> >> >> Best Regards, >> Jürgen >> >> >> >> On 3/20/21 8:45 PM, Peter Teeson wrote: >>> Hi Jürgen: >>> >>> It does indeed >>> >>> Gandalf:~ pteeson$ pkg-config --version >>> 0.29.2 >>> >>> I will look into installing GTK 3, re-builing & testing, and will report >>> back. >>> >>> Homebrew has installer for version 3 for Mojave, Catalina, and Big Sur. >>> <https://formulae.brew.sh/formula/gtk+3#default >>> <https://formulae.brew.sh/formula/gtk+3#default>> >>> >>> I have a question though - >>> >>> How do I find out what the dependancies are for the various add-on System >>> Quad functions? >>> >>> respect…. >>> >>> Peter >>>> On Mar 19, 2021, at 3:41 PM, Dr. Jürgen Sauermann >>>> <m...@xn--jrgen-sauermann-zvb.de <mailto:m...@xn--jrgen-sauermann-zvb.de>> >>>> wrote: >>>> >>>> Hi Peter, >>>> >>>> for GTK you need gtk+-3.0, The version on your box looks too old. >>>> >>>> Does Apple support pkg-config? In that case (and if gtk+3 is installed) >>>> then ./configure should find everything and pkg-config should say (e.g.): >>>> >>>> eedjsa@server68:~$ pkg-config --cflags gtk+-3.0 >>>> -pthread -I/usr/include/gtk-3.0 -I/usr/include/at-spi2-atk/2.0 >>>> -I/usr/include/at-spi-2.0 -I/usr/include/dbus-1.0 >>>> -I/usr/lib/x86_64-linux-gnu/dbus-1.0/include -I/usr/include/gtk-3.0 >>>> -I/usr/include/gio-unix-2.0/ -I/usr/include/cairo -I/usr/include/pango-1.0 >>>> -I/usr/include/harfbuzz -I/usr/include/pango-1.0 -I/usr/include/atk-1.0 >>>> -I/usr/include/cairo -I/usr/include/pixman-1 -I/usr/include/freetype2 >>>> -I/usr/include/libpng16 -I/usr/include/freetype2 -I/usr/include/libpng16 >>>> -I/usr/include/gdk-pixbuf-2.0 -I/usr/include/libpng16 >>>> -I/usr/include/glib-2.0 -I/usr/lib/x86_64-linux-gnu/glib-2.0/include >>>> >>>> eedjsa@server68:~$ pkg-config --libs gtk+-3.0 >>>> -lgtk-3 -lgdk-3 -lpangocairo-1.0 -lpango-1.0 -latk-1.0 -lcairo-gobject >>>> -lcairo -lgdk_pixbuf-2.0 -lgio-2.0 -lgobject-2.0 -lglib-2.0 >>>> >>>> Best Regards, >>>> Jürgen >>>> >>>> >>>> On 3/19/21 5:12 PM, Peter Teeson wrote: >>>>> Thanks very much Jürgen.. >>>>> >>>>> build log shows >>>>> ~/Desktop/ForJohn.txt:207: checking for gtk_init in -lgtk-3... no >>>>> >>>>> locate shows >>>>> /usr/local/opt/gtk >>>>> /usr/local/opt/gtk+ >>>>> >>>>> I don’t recall when or why I installed these libs. Maybe because Doxygen >>>>> required one or the other. >>>>> Anyhow it doesn’t really matter why they are there; my ./configure needs >>>>> fixing if I want to use ⎕PLOT. >>>>> >>>>> Since ⎕PLOT is an “extra” to APL I will file this thread so I can >>>>> remember these libs are needed. >>>>> My understanding of ./configure is that all of these additional System >>>>> functions are included by default in the build process. >>>>> >>>>> In this case it was only when trying to plot that the issue surfaced. >>>>> Well we learned a lot. >>>>> >>>>> respect >>>>> >>>>> Peter >>>>> >>>>>> On Mar 19, 2021, at 8:41 AM, Dr. Jürgen Sauermann >>>>>> <m...@xn--jrgen-sauermann-zvb.de >>>>>> <mailto:m...@xn--jrgen-sauermann-zvb.de>> wrote: >>>>>> >>>>>> Gentlemen, >>>>>> >>>>>> I suppose all you need is to tell ./configure where to find the >>>>>> additional include >>>>>> and library files for X11, e.g.: >>>>>> >>>>>> CXXFLAGS="-I /an_extra_include_path -I /another_include_path" \ >>>>>> LDFLAGS="-L /an_extra_library_path -L /another_library_path" \ >>>>>> ./configure <your-configure-options> >>>>>> >>>>>> Note that \ is THE trailing character in the first two lines (so that >>>>>> the above >>>>>> becomes a single line) and that there are NO whitespace before =. >>>>>> >>>>>> Then check the output of ./configure as to if all relevant components >>>>>> for ⎕PLOT were found: >>>>>> >>>>>> checking xcb/xcb.h usability... yes >>>>>> checking xcb/xcb.h presence... yes >>>>>> checking for xcb/xcb.h... yes >>>>>> checking X11/Xlib.h usability... yes >>>>>> checking X11/Xlib.h presence... yes >>>>>> checking for X11/Xlib.h... yes >>>>>> checking X11/Xlib-xcb.h usability... yes >>>>>> checking X11/Xlib-xcb.h presence... yes >>>>>> checking for X11/Xlib-xcb.h... yes >>>>>> checking X11/Xutil.h usability... yes >>>>>> checking X11/Xutil.h presence... yes >>>>>> checking for X11/Xutil.h... yes >>>>>> >>>>>> Note also that xcb has some issues with Unicode characters that make >>>>>> in particular APL characters in window titles and inside the plot windows >>>>>> unreadable. Try to use GTK3 instead. >>>>>> >>>>>> Best Regards, >>>>>> Jürgen >>>>>> >>>>>> >>>>>> On 3/19/21 3:52 AM, Peter Teeson wrote: >>>>>>> P.S. Gandalf:~ pteeson$ ls -al /usr/X11 >>>>>>> lrwxr-xr-x 1 root wheel 8 9 Jul 2020 /usr/X11 -> /opt/X11 >>>>>>> Gandalf:~ pteeson$ ls -al /opt/X11 >>>>>>> total 0 >>>>>>> drwxr-xr-x 9 root wheel 288 27 Sep 2016 . >>>>>>> drwxr-xr-x 3 root wheel 96 26 Sep 2016 .. >>>>>>> drwxr-xr-x 128 root wheel 4096 9 Jul 2020 bin >>>>>>> drwxr-xr-x 4 root wheel 128 29 Oct 2016 etc >>>>>>> drwxr-xr-x 19 root wheel 608 9 Jul 2020 include >>>>>>> drwxr-xr-x 204 root wheel 6528 9 Jul 2020 lib >>>>>>> drwxr-xr-x 4 root wheel 128 26 Oct 2016 libexec >>>>>>> drwxr-xr-x 14 root wheel 448 27 Sep 2016 share >>>>>>> drwxr-xr-x 5 root wheel 160 27 Sep 2016 var >>>>>>> >>>>>>>> On Mar 18, 2021, at 10:32 PM, Peter Teeson <peter.tee...@me.com >>>>>>>> <mailto:peter.tee...@me.com>> wrote: >>>>>>>> >>>>>>>> Hi John: >>>>>>>> >>>>>>>> Same issue here…(svn 1410) on Mojave 10.14.6. >>>>>>>> I have copied the list. >>>>>>>> >>>>>>>> ⎕PLOT '' >>>>>>>> SYNTAX ERROR+ >>>>>>>> ⎕PLOT ‘' >>>>>>>> >>>>>>>> I searched the bug-app archives and there was a bunch of emails last >>>>>>>> summer about missing X11. >>>>>>>> <https://lists.gnu.org/archive/html/bug-apl/2020-08/msg00000.html >>>>>>>> <https://lists.gnu.org/archive/html/bug-apl/2020-08/msg00000.html>> >>>>>>>> <— read this >>>>>>>> >>>>>>>> Never use ⎕PLOT myself. But I did find X11 in my build log: >>>>>>>> >>>>>>>> checking for XGetXCBConnection in -lX11-xcb... no >>>>>>>> checking for XOpenDisplay in -lX11... no >>>>>>>> >>>>>>>> When I do locate X11 in Terminal I get this >>>>>>>> /opt/X11 >>>>>>>> /usr/X11 >>>>>>>> >>>>>>>> So maybe that’s the issue? >>>>>>>> Need to fix $PATH for GNU APL build?? >>>>>>>> >>>>>>>> respect >>>>>>>> >>>>>>>> Peter >>>>>>>>> On Mar 18, 2021, at 4:25 PM, John Helm <jh...@usa.net >>>>>>>>> <mailto:jh...@usa.net>> wrote: >>>>>>>>> Hello Peter - >>>>>>>>> >>>>>>>>> Please forgive me in advance for reaching out directly, but I fear I >>>>>>>>> have a local problem and don't want to spam the list. >>>>>>>>> >>>>>>>>> I just tried your clone suggestion below and it fails for me... >>>>>>>>> >>>>>>>>> I built a VMware Fusion virtual machine with a clean install of >>>>>>>>> Mojave 10.14.6 >>>>>>>>> Installed the XCode command line tools >>>>>>>>> Ran: git clone https://git.savannah.gnu.org/git/apl.git >>>>>>>>> <https://git.savannah.gnu.org/git/apl.git> >>>>>>>>> cd trunk, followed by ./configure, make, sudo make install >>>>>>>>> Installed the apl keyboard and tested with ⎕plot '', which returns a >>>>>>>>> syntax error instead of the ⎕plot message. >>>>>>>>> I have repeated this exercise with High Sierra and Catalina on >>>>>>>>> physical machines with the same result. >>>>>>>>> >>>>>>>>> Also, I performed a MacPorts install on High Sierra and Catalina on >>>>>>>>> physical machines; again, with the same result. >>>>>>>>> >>>>>>>>> I spend much of my time in OS X command shell (iTerm2, to be >>>>>>>>> specific) and seldom have this much difficulty doing builds. >>>>>>>>> Nonetheless, I'm okay with being guilty of user-error until proven >>>>>>>>> innocent. In any case it seems clear that something big-and-basic is >>>>>>>>> wrong. >>>>>>>>> >>>>>>>>> Would you be willing to send me the console log of one of your >>>>>>>>> successful builds? This would let me do a diff against my build logs >>>>>>>>> and possibly give me some clues as to what I'm doing wrong. >>>>>>>>> >>>>>>>>> Kind regards, >>>>>>>>> >>>>>>>>> John >>>>>>>>> >>>>>>>>> On 3/7/21 9:59 PM, Peter Teeson wrote: >>>>>>>>>> Hi Jürgen: >>>>>>>>>> >>>>>>>>>> As promised a brief update note. >>>>>>>>>> >>>>>>>>>> On a clean install of macOS Mojave 10.14.6 I confirm that using >>>>>>>>>> git clone https://git.savannah.gnu.org/git/apl.git >>>>>>>>>> <https://git.savannah.gnu.org/git/apl.git> just works. >>>>>>>>>> >>>>>>>>>> And with the default settings the Terminal waltz builds clean. >>>>>>>>>> And APL executes. >>>>>>>>>> >>>>>>>>>> My hardware is an Early 2009 Mac Pro and so far there has never been >>>>>>>>>> a need >>>>>>>>>> to patch the installer from 2009 Snow Leopard 10.6 thru to 2018 >>>>>>>>>> Mojave 10.14. >>>>>>>>>> >>>>>>>>>> I did apply a patch to the firmware to make it a 5,1 from the >>>>>>>>>> original 4,1. >>>>>>>>>> Will look into whether it’s reasonable to install Catalina and Bug >>>>>>>>>> Sur. >>>>>>>>>> >>>>>>>>>> respect >>>>>>>>>> >>>>>>>>>> Peter >>>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>> >> >
