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");
dlopen("/usr/local/lib/apl/libapl.so",RTLD_NOW|RTLD_GLOBAL);
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
respect….
Peter
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.
respect
Peter
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 < loke...@gmail.com>
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,
<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
--
Br,
/Alexey
|
signature.asc