FWIW re "Apple has deprecated a whole bunch of things with Mojave and later. Including Open GL Open CL."
"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
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.
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
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:#if HAVE_LIBX11 &&
HAVE_LIBXCB && HAVE_LIBX11_XCB &&
HAVE_X11_XLIB_XCB_H
src/Quad_FFT.cc:#if defined(HAVE_LIBFFTW3)
&& defined(HAVE_FFTW3_H)
src/Quad_PLOT.cc:# if defined( HAVE_LIBX11 )
src/Quad_PLOT.cc:# if defined( HAVE_LIBXCB )
src/Quad_PLOT.cc:#i
src/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.
I have a question though -
How do I find out what the dependancies are for
the various add-on System Quad functions?
respect….
Peter
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
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
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.
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
So
maybe that’s
the issue?
Need
to fix $PATH
for GNU APL
build??
respect
Peter
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
- 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
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
|