[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Juergen Sauermann
Subject: Re: [Bug-apl] libapl load problem....UPDATE 2
Date: Sun, 20 May 2018 21:44:24 +0200
User-agent: Mozilla/5.0 (X11; Linux i686; rv:52.0) Gecko/20100101 Thunderbird/52.3.0

Hi Peter,

init_libapl is contained in the libapl.so.

As far as I understand, there are two ways to link libapl with your application:

1. link it at compile time (with the -lapl linker option) or
2. dlopen() it at runtime (your approach).

In case 2. the symbol init_libapl is NOT resolved by dlopen() but has to be resolved via dlsym() and
then called with the return value of dlsym(). There might also exist some (usually platform specific) linker options that
cause dlopen() to resolve all symbols provided in a shared library automatically, but I don't know.

I should mention that libapl is mainly a work of Dirk Laurie, I suppose he does not use dlopen(), but uses approach 1.
Maybe Dirk can give you some more hints about how to use libapl.

Sometimes using libtool helps to fix this kind of problems.

Best Regards,
/// Jürgen

On 05/20/2018 08:02 PM, Peter Teeson wrote:
Thanks Jürgen. Now I have another problem.
The libAPL (libapl) html documentation first line states:
"libapl is a C library,…..” so in theory it should play nicely with Obj-C.
But this tiny test C program is causing me a linker problem that I do not understand

#include <stdio.h>
#include <dlfcn.h>
#include "/usr/local/include/apl/libapl.h"
int main(int argc, const char * argv[]) {
    // insert code here...init_libap
    printf("Hello, World!\n");
    init_libapl("main", 0);
    return 0;

Undefined symbols for architecture x86_64:
  "_init_libapl", referenced from:
      _main in main.o
ld: symbol(s) not found for architecture x86_64
clang: error: linker command failed with exit code 1 (use -v to see invocation)

I typed this in Terminal
Gandalf:~ pteeson$ file /usr/local/lib/apl/libapl.so
/usr/local/lib/apl/libapl.so: Mach-O 64-bit bundle x86_64
Gandalf:~ pteeson$ nm /usr/local/lib/apl/libapl.so | grep init_libapl
00000000001975a0 T _init_libapl



On May 20, 2018, at 9:40 AM, Juergen Sauermann <address@hidden> wrote:

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.


 <address@hidden> wrote:


Last time I had a similar problem I had to run
autoconf/autoreconf/something like this to regenerate configure on OSX.

Elias Mårtenson <address@hidden> 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


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



On May 17, 2018, at 12:10 PM, Peter Teeson
<address@hidden> wrote:

Hi all:
The following is for svn 1048 ./configure —with-android
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,
if (NULL == libaplHandle) {
char *error = dlerror();
printf("AppDelegate - dlopen(libaplHandle) 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




Attachment: signature.asc
Description: OpenPGP digital signature

reply via email to

[Prev in Thread] Current Thread [Next in Thread]