libapl build bug--a cautionary tale

2022-03-10 Thread Chris Moller 

I just tried to build 1537 with libapl:

   ./configure --with-libapl

When you do that, the final link blows up with a couple hundred lines of 
variations of:


   /usr/bin/ld: /usr/local/lib/libfftw3.a(apiplan.o): relocation
   R_X86_64_32S against `.rodata' can not be used when making a shared
   object; recompile with -fPIC

the variations being all the *.o files in libfftw3.a: 
import-system-wisdom.o, import-wisdom-from-file.o, etc.


It turns that if you build fftw from fftw-3.3.10.tar.gz with the default 
./configure, it only builds the .a library and not the .so shared 
library.  This works in the apl build if you're just building executable 
apl, though you're probably linking against libfftw3.a, but dies if 
you're building libapl.


You can make fftw build the .so* libs by configuring with:

   ./configure --enable-shared

after which the libapl build works.



OpenPGP_0xDA6C0193083E.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature

]DOXY bug

2022-03-10 Thread Chris Moller 

Hi, Jürgen,

A few months ago, Russ/Russtopia sent me an edif bug that I've only just 
now had time to look at:


   [0] ~/Downloads/apl-1537/src >./apl --noCONT
 'libedif.so' ⎕fx 'edif'
   edif
 ]DOXY


   ===
   SEGMENTATION FAULT

   
   -- Stack trace at main.cc:95
   
   0x7FA5EEFB91E2 __libc_start_main
   0x4E784F  main
   0x691FB5   Workspace::immediate_execution(bool)
   0x543B2C    Command::process_line()
   0x543C93 Command::process_line(UCS_string&)
   0x54503D  Command::do_APL_command(std::ostream&, UCS_string&)
   0x548314   Command::cmd_DOXY(std::ostream&, UCS_string_vector&)
   0x53AF2D    Doxy::gen()
   0x53D95B Doxy::set_call_graph_root(UserFunction const*)
   0x7FA5EF6161B0
   0x4E667C
   
   

Starting apl under gdb, what's happening is that in 
Doxy.cc(set_call_graph_root):772,


   const UserFunction * ufun = fun->get_func_ufun();

ufun is getting set to null--it always seems to from 
Function.hh:177--and then, in Doxy.cc:774,


   aliases.push_back(ufun->get_name());

blows up.

I noticed that in Executable::clear_body(),

   const UserFunction * ufun = fun->get_func_ufun();

is followed by

   if (ufun && ufun->is_lambda())...

Patching Doxy.cc with:

773,774c773,777
<    nodes.push_back(ufun);
<    aliases.push_back(ufun->get_name());
---
>  if (ufun)
>    {
>  nodes.push_back(ufun);
>  aliases.push_back(ufun->get_name());
>    }

seems to work make things work, but I don't know if you have any 
regression tests that test the patch more thoroughly than I can.


Chris


OpenPGP_0xDA6C0193083E.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature

Updated edif release

2022-03-10 Thread Chris Moller 
For any edif users out there, there's an update against apl 1537 at 
https://github.com/ChrisMoller/edif


OpenPGP_0xDA6C0193083E.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature