|
From: | Peter Teeson |
Subject: | Re: [Bug-apl] libapl load problem....UPDATE |
Date: | Sat, 19 May 2018 15:53:31 -0400 |
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 <address@hidden> wrote:
|
[Prev in Thread] | Current Thread | [Next in Thread] |