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 <[email protected]> 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
>> <[email protected] <mailto:[email protected]>> 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 <[email protected]
>>> <mailto:[email protected]>> 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 <[email protected]>
>>>>> <mailto:[email protected]> 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
>>>>>> <[email protected]> <mailto:[email protected]>
>>>>>> 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
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>
>>>
>>
>
