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> 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
> 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 lib_template_F12.la 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 lib_template_OP1.la 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> 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
>>> 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 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 lib_template_OP2.la
>>> lib_template_F0.0.dylib 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
>>> 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
>>>
>>>
>>>
>>>
>>
>
