[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Bug-apl] libapl load problem....UPDATE 2
From: |
Alexey Veretennikov |
Subject: |
Re: [Bug-apl] libapl load problem....UPDATE 2 |
Date: |
Sun, 20 May 2018 20:32:26 +0200 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/25.3.50 (gnu/linux) |
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
- [Bug-apl] libapl load problem...., Peter Teeson, 2018/05/17
- Re: [Bug-apl] libapl load problem...., Juergen Sauermann, 2018/05/17
- Re: [Bug-apl] libapl load problem...., Peter Teeson, 2018/05/17
- Re: [Bug-apl] libapl load problem...., Elias Mårtenson, 2018/05/17
- Re: [Bug-apl] libapl load problem...., Alexey Veretennikov, 2018/05/18
- Re: [Bug-apl] libapl load problem....UPDATE, Peter Teeson, 2018/05/19
- Re: [Bug-apl] libapl load problem....UPDATE, Juergen Sauermann, 2018/05/20
- Re: [Bug-apl] libapl load problem....UPDATE 2, Peter Teeson, 2018/05/20
- Re: [Bug-apl] libapl load problem....UPDATE 2, Alexey Veretennikov, 2018/05/20
- Re: [Bug-apl] libapl load problem....UPDATE 2,
Alexey Veretennikov <=
- Re: [Bug-apl] libapl load problem....UPDATE 2, Juergen Sauermann, 2018/05/20
- Re: [Bug-apl] libapl load problem....UPDATE 2, Peter Teeson, 2018/05/20
- Re: [Bug-apl] libapl load problem....UPDATE 2, Dirk Laurie, 2018/05/20
- Re: [Bug-apl] libapl load problem....UPDATE 3, Peter Teeson, 2018/05/24
- Re: [Bug-apl] libapl load problem....UPDATE 3, Juergen Sauermann, 2018/05/25
- Re: [Bug-apl] libapl load problem....UPDATE 3, Peter Teeson, 2018/05/25
- Re: [Bug-apl] libapl load problem....UPDATE 3, Juergen Sauermann, 2018/05/27