[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Bug-apl] libapl load problem....
From: |
Alexey Veretennikov |
Subject: |
Re: [Bug-apl] libapl load problem.... |
Date: |
Fri, 18 May 2018 08:33:32 +0200 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/25.3.50 (gnu/linux) |
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
- [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 <=
- 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, 2018/05/20
- 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