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

[Elias Mårtenson]

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, <address@hidden> 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 <address@hidden> 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