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
> <[email protected]> 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 <[email protected]> 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,
>> <[email protected]> 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
>> <[email protected]> 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
