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 <peter.tee...@icloud.com> 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 <stdio.h>
> #include <dlfcn.h>
> #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
> 00000000001975a0 T _init_libapl
>
> respect….
>
> Peter
>
> On May 20, 2018, at 9:40 AM, Juergen Sauermann
> <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
>
> <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 <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
>
>
--
Br,
/Alexey
