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