Re: [Bug-apl] libapl load problem....UPDATE
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
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
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,
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
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
Re: [Bug-apl] libapl load problem....UPDATE 2
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
#include
#include "/usr/local/include/apl/libapl.h"
int main(int argc, const char * argv[]) {
// insert code here...
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
001975a0 T _init_libapl
respect….
Peter
> On May 20, 2018, at 9:40 AM, Juergen Sauermann
> 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.
>>
>> respect
>> Peter
>>
>>> mailto:alexey.veretenni...@gmail.com>>
>>> 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 mailto: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,
mailto: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
mailto: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(libapl
Re: [Bug-apl] libapl load problem....UPDATE 2
Hi,
Shouldn't you do something like (removing include libapl.h)
typedef void (*init_libapl_t)(const char*, int);
void* handle =
dlopen("/usr/local/lib/apl/libapl.so",RTLD_NOW|RTLD_GLOBAL);
init_libapl_t init_libapl = (init_libapl_t*)dlsym(handle, "init_libapl");
init_libapl("main", 0);
?
Peter Teeson writes:
> 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
> #include
> #include "/usr/local/include/apl/libapl.h"
> int main(int argc, const char * argv[]) {
> // insert code here...
> 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
> 001975a0 T _init_libapl
>
> respect….
>
> Peter
>
> On May 20, 2018, at 9:40 AM, Juergen Sauermann
> 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.
>
> respect
> Peter
>
> 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 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,
> 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
> 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:
>
Re: [Bug-apl] libapl load problem....UPDATE 2
or just link against libapl (-lapl) and dont use dlopen..
Alexey Veretennikov writes:
> Hi,
>
> Shouldn't you do something like (removing include libapl.h)
>
> typedef void (*init_libapl_t)(const char*, int);
> void* handle =
> dlopen("/usr/local/lib/apl/libapl.so",RTLD_NOW|RTLD_GLOBAL);
>
> init_libapl_t init_libapl = (init_libapl_t*)dlsym(handle, "init_libapl");
> init_libapl("main", 0);
>
> ?
>
>
>
> Peter Teeson writes:
>
>> 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
>> #include
>> #include "/usr/local/include/apl/libapl.h"
>> int main(int argc, const char * argv[]) {
>> // insert code here...
>> 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
>> 001975a0 T _init_libapl
>>
>> respect….
>>
>> Peter
>>
>> On May 20, 2018, at 9:40 AM, Juergen Sauermann
>> 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.
>>
>> respect
>> Peter
>>
>> 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 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,
>> 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
>> 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.
>>
Re: [Bug-apl] libapl load problem....UPDATE 2
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
#include
#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
001975a0
T _init_libapl
respect….
Peter
On May 20, 2018, at 9:40 AM, Juergen Sauermann
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
Re: [Bug-apl] libapl load problem....UPDATE 2
Thank you gentlemen for your support. This is all new to me…..
Option 1 sounds reasonable to me. I guess I have to add libapl.so to the Xcode
project.
Sort of like what Apple calls a Framework. I will try that.
What is the -lapl option argument? The Xcode project does have a place to add
Other Library and Linker Flags.
respect…
Peter
> On May 20, 2018, at 3:44 PM, Juergen Sauermann
> wrote:
>
> 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
>> #include
>> #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
>> 001975a0 T _init_libapl
>>
>> respect….
>>
>> Peter
>>
>>> On May 20, 2018, at 9:40 AM, Juergen Sauermann
>>> mailto:juergen.sauerm...@t-online.de>>
>>> 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.
respect
Peter
> mailto:alexey.veretenni...@gmail.com>>
> 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 mailto: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
Re: [Bug-apl] libapl load problem....UPDATE 2
2018-05-20 21:44 GMT+02:00 Juergen Sauermann : > 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. I did this three years ago, using SVN 570 of GNU APL. In an ideal world, I would have checked after every SVN update that my application still works. In the real world, I have not touched it since and cannot remember much. :-( I currently have SVN 1048. When I tried it my application [1] (which runs GNU APL in parallel with Lua) just now, the Lua 5.2 version that I made on 29 May 2015 still works in a simple test. $ lua -l gnuapl Lua 5.3.4 Copyright (C) 1994-2017 Lua.org, PUC-Rio > …/gnuapl$ lua5.2 -l gnuapl Lua 5.2.4 Copyright (C) 1994-2015 Lua.org, PUC-Rio > =gnuapl.exec"4 4⍴⍳16" 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 > This seems to confirm that there is nothing wrong with libapl.so. Unfortunately I have no simple C main program, since everything runs through Lua. In particular, Lua's 'package.loadlib' function is used to load the current libapl.so. The code for that function is way above my code-reading ability. Sorry that I can't offer more help. -- Dirk [1] Those that are reasonably fluent in Lua and its C API can try it out: https://github.com/dlaurie/lua-gnuapl
