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 >>>> >>> >> >