Re: [Bug-apl] libapl load problem....UPDATE 8

I haven't checked. But having lib_file_io.dylib instead of lib_file_io.so might create problems with ⎕FX which uses dlopen. Can you check 'lib_file_io.so' ⎕FX 'FILE_IO' and subsequent FILE_IO functionalities still work or not? > On Jun 30, 2018, at 5:33 PM, Peter Teeson wrote: > > Hi J

Re: [Bug-apl] libapl load problem....UPDATE 8

Hi Xiao-Yong, true, but lib_file_io has been replaced by ⎕FIO and will be removed in the near future.  I would also suppose that lib_file_io.dylib can be renamed to lib_file_io.so after building it. /// Jürgen

Re: [Bug-apl] libapl load problem....UPDATE 8

Since .dylib is the standard extension for libraries on OSX, it's probably a better idea to have an #ifdef that checks for the operating system and chooses the correct extension based on it. If you ever wish to support Windows in the future, they use .DLL. On 2 July 2018 at 22:15, Juergen Sauerma

Re: [Bug-apl] libapl load problem....UPDATE 8

Hi Elias, that is actually what  thge native function interface is doing: it tries file, then file.so and then file.dylib. I suppose the line given by Xiao-Yong below was taken from the gnu.info documentation and is only misleading

Re: [Bug-apl] libapl load problem....UPDATE 8

Re: [Bug-apl] Possible bug in APL

I got that non-working version of apl-1.7.tar.gz from ftp.gnu.org/pub/gnu/apl, dated 17 March 2017, so I guess it's a bit out-of-date. I just now got a chance to pull down the savannah svn version, which ./configures fine, but there a few compile errors with g++ (GCC) 8.1.1 20180502 (Red Hat