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

[Peter Teeson]

Although I've lived in the Apple Xcode world for the last many years, I am not 
afraid of the command line.
So I’m trying to learn more about the way GNU APL is built from the command 
line using the autotools suite.
In particular building GNU APL as a library using the —with-libapl configures 
option.

I’ve run into some new file extensions in examining things and I would like 
confirmation that my understanding of their meaning:

Difference Between PIC, .o, .a, .lo, .so, .po (Po), .tpo (.TPo), .plo (Plo), 
(.TPlo).
Executive Summary
    PIC is position independent code
    .o is typically a non-PIC object file emitted by the compiler (before 
linker stage) 
        When linked with an exe, the code will be included in the executable -- 
we bind at link time.
    .a is typically an archive library containing one or more .o files 
[non-PIC]. 
        When linked with an exe, the particular "*.o" files in the archive will 
be inserted into the executable.
    .lo is generally a "library object" that contains PIC code whether manually 
compiled with gcc -fPIC or using libtool.
    .so files are "shared object" files. They contain PIC objects.
    .po (.Po) text files describing object files
    .tpo (.TPo) temporary text files describing object files
    .plo (.Plo) text file describing library object file
    .tplo (.TPlo) text file describing temporary library object

Am I correct?

Thanks & respect…

Peter

> On May 20, 2018, at 4:59 PM, Dirk Laurie <address@hidden> wrote:
> 2018-05-20 21:44 GMT+02:00 Juergen Sauermann <address@hidden>:
>> As far as I understand, there are two ways to link libapl with your
>> application:
>> 
>> 1. link it at compile time (with the -lapl linker option) or
>> 2. dlopen() it at runtime (your approach).
>> 
>> In case 2. the symbol init_libapl is NOT resolved by dlopen() but has to be
>> resolved via dlsym() and
>> then called with the return value of dlsym(). There might also exist some
>> (usually platform specific) linker options that
>> cause dlopen() to resolve all symbols provided in a shared library
>> automatically, but I don't know.
>> 
>> I should mention that libapl is mainly a work of Dirk Laurie, I suppose he
>> does not use dlopen(), but uses approach 1.
>> Maybe Dirk can give you some more hints about how to use libapl.
> 
> I did this three years ago, using SVN 570 of GNU APL. In an ideal
> world, I would have checked after every SVN update that my application
> still works. In the real world, I have not touched it since and cannot
> remember much. :-(
> 
> I currently have SVN 1048. When I tried it my application [1] (which
> runs GNU APL in parallel with Lua) just now, the Lua 5.2 version that
> I made on 29 May 2015 still works in a simple test.
> 
> $ lua -l gnuapl
> Lua 5.3.4  Copyright (C) 1994-2017 Lua.org, PUC-Rio
>> 
> …/gnuapl$ lua5.2 -l gnuapl
> Lua 5.2.4  Copyright (C) 1994-2015 Lua.org, PUC-Rio
>> =gnuapl.exec"4 4⍴⍳16"
> 1  2  3  4
> 5  6  7  8
> 9 10 11 12
> 13 14 15 16
>> 
> 
> This seems to confirm that there is nothing wrong with libapl.so.
> 
> Unfortunately I have no simple C main program, since everything runs
> through Lua. In particular, Lua's 'package.loadlib' function is used
> to load the current libapl.so. The code for that function is way above
> my code-reading ability.
> 
> Sorry that I can't offer more help.
> 
> -- Dirk
> 
> [1] Those that are reasonably fluent in Lua and its C API can try it
> out: https://github.com/dlaurie/lua-gnuapl