<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> 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 >>>>>> >>>>>> >>>>>> >>>>>> >> >> >
