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

[Alexey Veretennikov]

or just link against libapl (-lapl) and dont use dlopen..

Alexey Veretennikov <address@hidden> 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 <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