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

[Xiao-Yong Jin]

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 <address@hidden> 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 <address@hidden> 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
>>> 
>>> 
>>> 
>>> 
>> 
>