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

[Alexey Veretennikov]

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 <address@hidden> 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
>  <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.
>
>  respect
>  Peter
>
>  <address@hidden> 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 <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
>  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
>
>  -- 
>  Br,
>  /Alexey
>
>

-- 
Br,
/Alexey