Thank you gentlemen for your support. This is all new to me…..
Option 1 sounds reasonable to me. I guess I have to add libapl.so to the Xcode
project.
Sort of like what Apple calls a Framework. I will try that.
What is the -lapl option argument? The Xcode project does have a place to add
Other Library and Linker Flags.
respect…
Peter
> On May 20, 2018, at 3:44 PM, Juergen Sauermann
> <juergen.sauerm...@t-online.de> wrote:
>
> Hi Peter,
>
> init_libapl is contained in the libapl.so.
>
> 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.
>
> Sometimes using libtool helps to fix this kind of problems.
>
> Best Regards,
> /// Jürgen
>
>
>
> On 05/20/2018 08:02 PM, Peter Teeson wrote:
>> Thanks Jürgen. Now I have another problem.
>> The libAPL (libapl) html documentation first line states:
>> "libapl is a C library,…..” so in theory it should play nicely with Obj-C.
>> But this tiny test C program is causing me a linker problem that I do not
>> understand
>>
>> #include <stdio.h>
>> #include <dlfcn.h>
>> #include "/usr/local/include/apl/libapl.h"
>> int main(int argc, const char * argv[]) {
>> // insert code here...init_libap
>> printf("Hello, World!\n");
>> dlopen("/usr/local/lib/apl/libapl.so",RTLD_NOW|RTLD_GLOBAL);
>> init_libapl("main", 0);
>> return 0;
>> }
>>
>> Undefined symbols for architecture x86_64:
>> "_init_libapl", referenced from:
>> _main in main.o
>> ld: symbol(s) not found for architecture x86_64
>> clang: error: linker command failed with exit code 1 (use -v to see
>> invocation)
>>
>> I typed this in Terminal
>> Gandalf:~ pteeson$ file /usr/local/lib/apl/libapl.so
>> /usr/local/lib/apl/libapl.so: Mach-O 64-bit bundle x86_64
>> Gandalf:~ pteeson$ nm /usr/local/lib/apl/libapl.so | grep init_libapl
>> 00000000001975a0 T _init_libapl
>>
>> respect….
>>
>> Peter
>>
>>> On May 20, 2018, at 9:40 AM, Juergen Sauermann
>>> <juergen.sauerm...@t-online.de <mailto:juergen.sauerm...@t-online.de>>
>>> wrote:
>>>
>>> Hi Peter,
>>>
>>> thanks, I have added a typedef in libapl.h. SVN 1049.
>>>
>>> /// Jürgen
>>>
>>>
>>> On 05/19/2018 09:53 PM, Peter Teeson wrote:
>>>> Thank you all for your replies. I removed the configure arg —with-android.
>>>> Now there is no error from dlopen() or dlclose() or dlsym() .
>>>>
>>>> But we have a new problem… in this code libapl.h is missing a define for
>>>> APL_Float.
>>>>
>>>> #include "/usr/local/include/apl/libapl.h"
>>>> int main(int argc, const char * argv[]) {
>>>>
>>>> return 0;
>>>> }
>>>>
>>>> However if I add the followed 2 lines (copied from lines 72-73 in
>>>> APL_Types.hh) everything preprocesses just fine.
>>>>
>>>> typedef double APL_Float_Base;
>>>> typedef APL_Float_Base APL_Float;
>>>> #include "/usr/local/include/apl/libapl.h"
>>>>
>>>> int main(int argc, const char * argv[]) {
>>>>
>>>> return 0;
>>>> }
>>>>
>>>> Looking at the source code in APL_Types.hh I notice
>>>>
>>>> line 39 #define APL_Float_is_class 0
>>>>
>>>> and this in lines 62 -80
>>>> /// One (real) APL floating point value.
>>>> #if APL_Float_is_class // APL_Float is a class
>>>>
>>>> #include "APL_Float_as_class.hh"
>>>>
>>>> inline void release_APL_Float(APL_Float * x) { x->~APL_Float(); }
>>>>
>>>> #else // APL_Float is a POD (double)
>>>>
>>>> typedef double APL_Float_Base;
>>>> typedef APL_Float_Base APL_Float;
>>>>
>>>> #define complex_exponent(x) exp(x)
>>>> #define complex_power(x, y) pow((x), (y))
>>>> #define complex_sqrt(x) sqrt(x)
>>>> #define release_APL_Float(x)
>>>>
>>>> #endif // APL_Float is class vs. POD
>>>>
>>>> From this I conclude that somehow the typedefs weren’t included in the
>>>> pre-processing/compiling of libapl
>>>> Not quite sure how to track this down any further.
>>>>
>>>> respect
>>>> Peter
>>>>
>>>>> <alexey.veretenni...@gmail.com <mailto:alexey.veretenni...@gmail.com>>
>>>>> wrote:
>>>>
>>>>>
>>>>> Hi,
>>>>>
>>>>> Last time I had a similar problem I had to run
>>>>> autoconf/autoreconf/something like this to regenerate configure on OSX.
>>>>>
>>>>> Elias Mårtenson <loke...@gmail.com <mailto:loke...@gmail.com>> writes:
>>>>>
>>>>>> I don't think so. I believe the reason is that you're not compiling
>>>>>> with a flat namespace.
>>>>>>
>>>>>> If I recall correctly OSX uses a different name resolution system
>>>>>> by default where symbols from one library doesn't automatically
>>>>>> become part of the namespace of another.
>>>>>>
>>>>>> There were some magic flags one can use with the linker to get
>>>>>> the normal behaviour from Linux, but I have no idea how it
>>>>>> works. I don't use OSX anymore so I can't really experiment with
>>>>>> it.
>>>>>>
>>>>>> Regards,
>>>>>> Elias
>>>>>>
>>>>>> On Fri, 18 May 2018, 08:14 Peter Teeson,
>>>>>> <peter.tee...@icloud.com <mailto:peter.tee...@icloud.com>> wrote:
>>>>>>
>>>>>> I’ve been thinking about this and I believe it’s probably
>>>>>> because libapl.so is C++ but Cocoa is Obj-C.
>>>>>> Pure C plays nicely with Obj-C but there needs to be
>>>>>> wrappers for C++ to play nicely with Obj-C.
>>>>>> So while I wait for your wise replies I will research what to
>>>>>> do to use C++ dlls in Obj-C; I don’t even know if that is
>>>>>> possible.
>>>>>>
>>>>>> respect….
>>>>>>
>>>>>> Peter
>>>>>>
>>>>>> On May 17, 2018, at 12:10 PM, Peter Teeson
>>>>>> <peter.tee...@icloud.com <mailto:peter.tee...@icloud.com>> wrote:
>>>>>>
>>>>>> Hi all:
>>>>>> The following is for svn 1048 ./configure —with-android
>>>>>> —with-libapl
>>>>>> Using MacOS Yosemite 10.10.5 and Xcode 6.4 and a
>>>>>> vanilla Cocoa Document app.
>>>>>>
>>>>>> In the AppDelegate code I have the following:
>>>>>>
>>>>>> void *libaplHandle; // plain C file pointer
>>>>>>
>>>>>> - (void)applicationDidFinishLaunching:(NSNotification
>>>>>> *)aNotification {
>>>>>> // Load libapl from default location.
>>>>>> const char* libaplPath="/usr/local/lib/apl/libapl.so"; // TO
>>>>>> DO Make this path a User Preference....}
>>>>>>
>>>>>> libaplHandle = dlopen(libaplPath,
>>>>>> RTLD_LAZY|RTLD_GLOBAL);
>>>>>> if (NULL == libaplHandle) {
>>>>>> char *error = dlerror();
>>>>>> printf("AppDelegate - dlopen(libaplHandle) error:
>>>>>> %s",error);
>>>>>> }
>>>>>> }
>>>>>>
>>>>>> AppDelegate - dlopen(libaplHandle) error:
>>>>>> dlopen(/usr/local/lib/apl/libapl.so, 9): Symbol
>>>>>> not found: _CERR
>>>>>> Referenced from: /usr/local/lib/apl/libapl.so
>>>>>> Expected in: flat namespace
>>>>>> in /usr/local/lib/apl/libapl.so
>>>>>>
>>>>>> I really have no idea why this happens. Please
>>>>>> educate me…..
>>>>>>
>>>>>> Thanks and
>>>>>>
>>>>>> respect…..
>>>>>>
>>>>>> Peter
>>>>>>
>>>>>>
>>>>>
>>>>> --
>>>>> Br,
>>>>> /Alexey
>>>>
>>>
>>
>
