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

[Juergen Sauermann]

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

signature.asc
Description: OpenPGP digital signature