Gandalf:~ pteeson$ nano libapl_test.c #include "/usr/local/include/apl/libapl.h"
int main (int argc, char * argv[]) { init_libapl(argv[0],0); return apl_exec("⎕←2 3⍴⍳6"); } Gandalf:~ pteeson$ gcc -o libapl_test libapl_test.c -L /usr/local/lib/apl/ -lapl Gandalf:~ pteeson$ ./libapl_test 1 2 3 4 5 6 Gandalf:~ pteeson$ Thanks to everyone….. per ardua ad astra…. respect…. Peter > On Jul 2, 2018, at 2:34 PM, Peter Teeson <peter.tee...@icloud.com> wrote: > > <https://developer.apple.com/library/archive/documentation/DeveloperTools/Conceptual/DynamicLibraries/000-Introduction/Introduction.html#//apple_ref/doc/uid/TP40001908-SW1 > > <https://developer.apple.com/library/archive/documentation/DeveloperTools/Conceptual/DynamicLibraries/000-Introduction/Introduction.html#//apple_ref/doc/uid/TP40001908-SW1>> > From Apple’s Dynamic Libraries Programming Topics documentation - it’s an > essential guide IMHO > "To load dynamic libraries at runtime, apps should use a set of efficient and > portable functions, called dynamic loader compatibility functions. Using > these functions ensures that dynamic libraries are loaded in the most > efficient way and facilitates the porting of apps from one platform to > another. > This document is intended for developers of dynamic libraries and developers > who use dynamic libraries in their apps. You should be familiar with the Mac > OS, UNIX, Solaris, or Linux operating systems. You should also be an > experienced C, C++, or Objective-C programmer. > > This document explains how dynamic libraries are loaded at app launch time > and how to use the DLC functions, dlopen, dlsym, dladdr, dlclose, and > dlerror, to load dynamic libraries at runtime. This document also provides > guidelines for developing dynamic libraries to be used by client apps. " > > respect…. > > Peter >> On Jul 2, 2018, at 11:32 AM, Juergen Sauermann >> <juergen.sauerm...@t-online.de <mailto:juergen.sauerm...@t-online.de>> wrote: >> >> 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 when taken out of its context, The example in gnu.info was >> assuming the presence a file >> lib_file_io.so and then explains how to use ⎕FX given that file. I suppose >> OSX users are smart >> enough to figure that the file names on their platform end with .dylib >> instead of .so. >> >> /// Jürgen >> >> >> On 07/02/2018 04:18 PM, Elias Mårtenson wrote: >>> 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 Sauermann <juergen.sauerm...@t-online.de >>> <mailto:juergen.sauerm...@t-online.de>> wrote: >>> 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 >>> >>> >>> On 07/02/2018 03:44 PM, Xiao-Yong Jin wrote: >>>> 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 <peter.tee...@icloud.com> >>>>> <mailto:peter.tee...@icloud.com> wrote: >>>>> >>>>> Hi Jürgen: >>>>> >>>>> Good news…. That seems to have worked. >>>>> I deleted the /usr/local/lib/apl dir as well as the >>>>> /usr/local/include/apl dir >>>>> >>>>> In my case I had to install the following auto tools: >>>>> autoconf-2.69 libtool-2.4.6 automake-1.15 >>>>> >>>>> Then Gandalf:~ pteeson$ svn co http://svn.savannah.gnu.org/svn/apl/trunk >>>>> <http://svn.savannah.gnu.org/svn/apl/trunk> gnuapl >>>>> >>>>> Then followed items 1-5 per your instructions. >>>>> >>>>> Then Gandalf:~ pteeson$ ls /usr/local/lib/apl >>>>> lib_file_io.0.dylib lib_template_F12.0.dylib libapl.0.dylib >>>>> lib_file_io.a lib_template_F12.a libapl.a >>>>> lib_file_io.dylib lib_template_F12.dylib libapl.dylib >>>>> lib_file_io.la <http://lib_file_io.la/> lib_template_F12.la >>>>> libapl.la <http://libapl.la/> >>>>> lib_sql.0.dylib lib_template_OP1.0.dylib libemacs.0.dylib >>>>> lib_sql.a lib_template_OP1.a libemacs.a >>>>> lib_sql.dylib lib_template_OP1.dylib libemacs.dylib >>>>> lib_sql.la <http://lib_sql.la/> lib_template_OP1.la >>>>> libemacs.la <http://libemacs.la/> >>>>> lib_template_F0.0.dylib lib_template_OP2.0.dylib workspaces >>>>> lib_template_F0.a lib_template_OP2.a wslib3 >>>>> lib_template_F0.dylib lib_template_OP2.dylib wslib4 >>>>> lib_template_F0.la lib_template_OP2.la wslib5 >>>>> >>>>> Note that some of the .dylibs have version numbers as part of the lib >>>>> name. >>>>> This conforms to Apple’s Dynamic Libraries Programming Topics >>>>> documentation >>>>> >>>>> So far so good… I will now proceed with the original experiment…. >>>>> >>>>> Thanks for the help and support….. >>>>> >>>>> respect…. >>>>> >>>>> Peter >>>>> >>>>>> On Jun 30, 2018, at 6:00 AM, Juergen Sauermann >>>>>> <juergen.sauerm...@t-online.de> <mailto:juergen.sauerm...@t-online.de> >>>>>> wrote: >>>>>> >>>>>> Hi Peter, >>>>>> >>>>>> if I compare the rules in Makefile.am for the libraries mentioned below, >>>>>> then it seems >>>>>> like there is one line which sets the xxx_la_LDFLAGS for those libraries >>>>>> xxx that then fail >>>>>> to properly build the dylibs. Removing that line may fix your problem >>>>>> (it may create >>>>>> others but we willl see), >>>>>> >>>>>> Please try the following: >>>>>> >>>>>> 1. remove the line that reads: >>>>>> >>>>>> lib_file_io_la_LDFLAGS = -avoid-version -module -shared -export-dynamic >>>>>> >>>>>> from file src/native/Makefile.am >>>>>> >>>>>> >>>>>> 2. remove the line that reads: >>>>>> >>>>>> libapl_la_LDFLAGS += -avoid-version -module -shared -export-dynamic >>>>>> >>>>>> from file src/Makefile.am >>>>>> >>>>>> >>>>>> 3. run command autoreconf in the top-level directory (the one that has >>>>>> the subdir named src). That >>>>>> creates a fresh Makefile.in file for every Makefile.am, >>>>>> >>>>>> >>>>>> 4. run ./configure --with-libapl >>>>>> >>>>>> >>>>>> 5. run make and sudo make install >>>>>> >>>>>> >>>>>> It may or may not be necessary to run make clean before step 5 in the >>>>>> src and src/native.directories if >>>>>> there should be stale .la files. >>>>>> >>>>>> /// Jürgen >>>>>> >>>>>> >>>>>> On 06/29/2018 07:52 PM, Peter Teeson wrote: >>>>>>> Hi Jürgen: >>>>>>> Sorry for delayed reply I was AFK. >>>>>>> I just now did the following: >>>>>>> (0) Made a new partition (logical volume) and >>>>>>> installed macOS Yosemite 10.10.5 >>>>>>> installed Command LineTools (Apple's package of ld, libel, >>>>>>> make, gcc, etc, etc) >>>>>>> (1) Checked out svn1053 in new dir gnuapl in my home dir >>>>>>> Gandalf:~ pteeson$ pwd /Users/pteeson >>>>>>> Gandalf:~ pteeson$ svn co >>>>>>> http://svn.savannah.gnu.org/svn/apl/trunk >>>>>>> <http://svn.savannah.gnu.org/svn/apl/trunk> >>>>>>> gnuapl >>>>>>> (2) Gandalf:~ pteeson$ cd gnuapl >>>>>>> (3) Gandalf:gnuapl pteeson$ ./configure --with-libapl >>>>>>> checking for gcc... gcc >>>>>>> …... >>>>>>> (4) make >>>>>>> Gandalf:gnuapl pteeson$ make >>>>>>> /Library/Developer/CommandLineTools/usr/bin/make all-recursive >>>>>>> Making all in build >>>>>>> ….. >>>>>>> >>>>>>> libtool: link: g++ -Wl,-undefined -Wl,dynamic_lookup -o >>>>>>> .libs/libapl.so -bundle ,,,,, >>>>>>> (5) sudo make install >>>>>>> libtool: install: /usr/bin/install -c .libs/libapl.so >>>>>>> /usr/local/lib/apl/libapl.so >>>>>>> >>>>>>> So completely vanilla, out of the box, build. >>>>>>> >>>>>>> Gandalf:gnuapl pteeson$ ls /usr/local/lib/apl >>>>>>> lib_file_io.la <http://lib_file_io.la/> >>>>>>> lib_template_OP1.dylib >>>>>>> lib_file_io.so lib_template_OP1.la >>>>>>> lib_sql.0.dylib lib_template_OP2.0.dylib >>>>>>> lib_sql.a lib_template_OP2.a >>>>>>> lib_sql.dylib lib_template_OP2.dylib >>>>>>> lib_sql.la <http://lib_sql.la/> >>>>>>> lib_template_OP2.la >>>>>>> lib_template_F0.0.dylib libapl.la <http://libapl.la/> >>>>>>> lib_template_F0.a libapl.so >>>>>>> lib_template_F0.dylib libemacs.0.dylib >>>>>>> lib_template_F0.la libemacs.a >>>>>>> lib_template_F12.0.dylib libemacs.dylib >>>>>>> lib_template_F12.a libemacs.la >>>>>>> <http://libemacs.la/> >>>>>>> lib_template_F12.dylib workspaces >>>>>>> lib_template_F12.la wslib3 >>>>>>> lib_template_OP1.0.dylib wslib4 >>>>>>> lib_template_OP1.a wslib5 >>>>>>> >>>>>>> What I find interesting is that most of the libraries are either .a, >>>>>>> .la, or .dylib. >>>>>>> But the exceptions are lib_file_io.so and libapl.so >>>>>>> >>>>>>> So the gnuapl package, as a checked out, knows how to make .dylibs. >>>>>>> It’s just those two that seem to have a problem. >>>>>>> >>>>>>> How do we figure out what we need to do to fix them? >>>>>>> >>>>>>> BTW I have the complete Terminal output saved if we need to dig into it. >>>>>>> >>>>>>> respect…. >>>>>>> >>>>>>> Peter >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>> >>> >> >