Re: GNU APL on Mojave 10.14.6, and others

[Peter Teeson]

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 <mail@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.teeson@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>   <— 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 <jhelm@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
• 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 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