Prev: Creating a new method with TclOO and the C api
Next: Ariadne Designs Ltd
From: Alexandre Ferrieux on 22 Jul 2010 08:42
On Jul 22, 1:47 pm, Georgios Petasis <peta...(a)iit.demokritos.gr>
wrote:
> Στις 21/7/2010 09:57, ο/η Alexandre Ferrieux έγραψε:
>
>
>
>
>
> > On Jul 21, 8:09 am, Georgios Petasis<peta...(a)iit.demokritos.gr>
> > wrote:
> >> Στις 20/7/2010 19:12, ο/η Alexandre Ferrieux έγραψε:
>
> >>> On Jul 20, 2:39 pm, Georgios Petasis<peta...(a)iit.demokritos.gr>
> >>> wrote:
> >>>> Στις 20/7/2010 14:00, ο/η Alexandre Ferrieux έγραψε:
>
> >>>>> On Jul 20, 11:46 am, Georgios Petasis<peta...(a)iit.demokritos.gr>
> >>>>> wrote:
> >>>>>> Στις 20/7/2010 08:49, ο/η Donal K. Fellows έγραψε:
>
> >>>>>>> On Jul 17, 11:40 am, Georgios Petasis<peta...(a)iit.demokritos.gr>
> >>>>>>> wrote:
> >>>>>>>> I am facing a problem with two dynamic libraries that implement some
> >>>>>>>> commands in C.
>
> >>>>>>>> I have library A, which depends only on system libraries (libstdc++&
> >>>>>>>> libSystem.B), which gets loaded ok in Tcl:
> >>>>>>> [...]
> >>>>>>>> I have then library B, which depends on A:
> >>>>>>> [...]
> >>>>>>>> So, I have loaded A through "load", but when I try to load B, I get an
> >>>>>>>> error:
> >>>>>>> [...]
> >>>>>>>> But libCDM.dylib has been loaded by the process, and its commands are
> >>>>>>>> available.
>
> >>>>>>>> Any idea on what may be wrong?
>
> >>>>>>> Curious. Looks like it is not registering the fact that the library is
> >>>>>>> present. (This might be a deliberate move on Apple's part to stop code
> >>>>>>> from getting at APIs that it shouldn't have anything to do with.)
>
> >>>>>>> Since both libraries are Tcl-aware, maybe you could try having one
> >>>>>>> export a stubbed ABI that the other uses, with the other using the
> >>>>>>> first through that. (The two are stitched together with a wrapper
> >>>>>>> round [package require].) For an example of how to build the library
> >>>>>>> so as to do that, see the TclOO-as-extension-package code. (Adapting
> >>>>>>> the consumer side should be easy enough.)
>
> >>>>>>> Donal.
>
> >>>>>> Yes, it is really strange. I am not sure that I understood the stubbed
> >>>>>> ABI solution you propose (the library is linked by many dlls actually,
> >>>>>> not all tcl-related) :-)
>
> >>>>>> However, looking (for many hours) on the net, led me to a deprecated
> >>>>>> function(!):https://developer.mozilla.org/en/Using_Dependent_Libraries_In_Extensi...
>
> >>>>>> There is a function named NSAddImage:http://developer.apple.com/mac/library/documentation/DeveloperTools/R...
>
> >>>>>> If I call this function with the shared library that the whole
> >>>>>> application must see, with the parameters
> >>>>>> NSADDIMAGE_OPTION_RETURN_ON_ERROR |
> >>>>>> NSADDIMAGE_OPTION_WITH_SEARCHING |
> >>>>>> NSADDIMAGE_OPTION_MATCH_FILENAME_BY_INSTALLNAME
>
> >>>>>> it does the obvious: the loaded shared library is visible to other
> >>>>>> shared libraries, as it should.
>
> >>>>>> Of course, the problem is that the function is already deprecated.
> >>>>>> So, I have to find an alternative to this :-(
>
> >>>>> Out of curiosity, is all this so different from dlopen's RTLD_GLOBAL ?
>
> >>>>> -Alex
>
> >>>> According to my understanding (file unix/tclLoadDyld.c), tcl already
> >>>> does dlopen(path, RTLD_NOW | RTLD_GLOBAL) while loading the dylib.
> >>>> If this is the case, then yes, NSAddImage does something very different
> >>>> than dlopen(RTLD_GLOBAL). The loaded library with dlopen is not visible
> >>>> from other libraries loaded again with dlopen.
>
> >>>> This is really strange in OS X. It seems that the only advice from Apple
> >>>> is to place the library in common paths or make the executable depend on
> >>>> the library.
>
> >>> Wow. This is a mission for Daniel. Please open a bug and assign to
> >>> das. Not sure the fault is ultimately Tcl's (nearly sure it is not),
> >>> but that looks like yet another OS quirk that deserves a smart
> >>> workaround so that Tcl keeps a smooth surface ;-)
>
> >>> -Alex
>
> >> I really don't know if anything can be done. NSAddImage is already
> >> deprecated, and has the side effect that images loaded with it, cannot
> >> be unloaded. So, unload will stop working if something like this is
> >> added in load.
>
> > Of course, and I'm not proposing to use the NS* API either. What I'm
> > suggesting instead, is to record a ticket saying "dlopen(RTLD_GLOBAL)
> > doesn't work as advertised on OSX, help!!!"
>
> > -Alex
>
> Done:https://sourceforge.net/tracker/?func=detail&aid=3033027&group_id=108...

Thanks.

> But I don't think a solution is probable :-)

Look at the suggestion at the end of my comment there. Can you try
this refactoring ?

-Alex
From: Georgios Petasis on 22 Jul 2010 08:58
Στις 22/7/2010 15:42, ο/η Alexandre Ferrieux έγραψε:
> On Jul 22, 1:47 pm, Georgios Petasis<peta...(a)iit.demokritos.gr>
> wrote:
>> Στις 21/7/2010 09:57, ο/η Alexandre Ferrieux έγραψε:
>>
>>
>>
>>
>>
>>> On Jul 21, 8:09 am, Georgios Petasis<peta...(a)iit.demokritos.gr>
>>> wrote:
>>>> Στις 20/7/2010 19:12, ο/η Alexandre Ferrieux έγραψε:
>>
>>>>> On Jul 20, 2:39 pm, Georgios Petasis<peta...(a)iit.demokritos.gr>
>>>>> wrote:
>>>>>> Στις 20/7/2010 14:00, ο/η Alexandre Ferrieux έγραψε:
>>
>>>>>>> On Jul 20, 11:46 am, Georgios Petasis<peta...(a)iit.demokritos.gr>
>>>>>>> wrote:
>>>>>>>> Στις 20/7/2010 08:49, ο/η Donal K. Fellows έγραψε:
>>
>>>>>>>>> On Jul 17, 11:40 am, Georgios Petasis<peta...(a)iit.demokritos.gr>
>>>>>>>>> wrote:
>>>>>>>>>> I am facing a problem with two dynamic libraries that implement some
>>>>>>>>>> commands in C.
>>
>>>>>>>>>> I have library A, which depends only on system libraries (libstdc++&
>>>>>>>>>> libSystem.B), which gets loaded ok in Tcl:
>>>>>>>>> [...]
>>>>>>>>>> I have then library B, which depends on A:
>>>>>>>>> [...]
>>>>>>>>>> So, I have loaded A through "load", but when I try to load B, I get an
>>>>>>>>>> error:
>>>>>>>>> [...]
>>>>>>>>>> But libCDM.dylib has been loaded by the process, and its commands are
>>>>>>>>>> available.
>>
>>>>>>>>>> Any idea on what may be wrong?
>>
>>>>>>>>> Curious. Looks like it is not registering the fact that the library is
>>>>>>>>> present. (This might be a deliberate move on Apple's part to stop code
>>>>>>>>> from getting at APIs that it shouldn't have anything to do with.)
>>
>>>>>>>>> Since both libraries are Tcl-aware, maybe you could try having one
>>>>>>>>> export a stubbed ABI that the other uses, with the other using the
>>>>>>>>> first through that. (The two are stitched together with a wrapper
>>>>>>>>> round [package require].) For an example of how to build the library
>>>>>>>>> so as to do that, see the TclOO-as-extension-package code. (Adapting
>>>>>>>>> the consumer side should be easy enough.)
>>
>>>>>>>>> Donal.
>>
>>>>>>>> Yes, it is really strange. I am not sure that I understood the stubbed
>>>>>>>> ABI solution you propose (the library is linked by many dlls actually,
>>>>>>>> not all tcl-related) :-)
>>
>>>>>>>> However, looking (for many hours) on the net, led me to a deprecated
>>>>>>>> function(!):https://developer.mozilla.org/en/Using_Dependent_Libraries_In_Extensi...
>>
>>>>>>>> There is a function named NSAddImage:http://developer.apple.com/mac/library/documentation/DeveloperTools/R...
>>
>>>>>>>> If I call this function with the shared library that the whole
>>>>>>>> application must see, with the parameters
>>>>>>>> NSADDIMAGE_OPTION_RETURN_ON_ERROR |
>>>>>>>> NSADDIMAGE_OPTION_WITH_SEARCHING |
>>>>>>>> NSADDIMAGE_OPTION_MATCH_FILENAME_BY_INSTALLNAME
>>
>>>>>>>> it does the obvious: the loaded shared library is visible to other
>>>>>>>> shared libraries, as it should.
>>
>>>>>>>> Of course, the problem is that the function is already deprecated.
>>>>>>>> So, I have to find an alternative to this :-(
>>
>>>>>>> Out of curiosity, is all this so different from dlopen's RTLD_GLOBAL ?
>>
>>>>>>> -Alex
>>
>>>>>> According to my understanding (file unix/tclLoadDyld.c), tcl already
>>>>>> does dlopen(path, RTLD_NOW | RTLD_GLOBAL) while loading the dylib.
>>>>>> If this is the case, then yes, NSAddImage does something very different
>>>>>> than dlopen(RTLD_GLOBAL). The loaded library with dlopen is not visible
>>>>>> from other libraries loaded again with dlopen.
>>
>>>>>> This is really strange in OS X. It seems that the only advice from Apple
>>>>>> is to place the library in common paths or make the executable depend on
>>>>>> the library.
>>
>>>>> Wow. This is a mission for Daniel. Please open a bug and assign to
>>>>> das. Not sure the fault is ultimately Tcl's (nearly sure it is not),
>>>>> but that looks like yet another OS quirk that deserves a smart
>>>>> workaround so that Tcl keeps a smooth surface ;-)
>>
>>>>> -Alex
>>
>>>> I really don't know if anything can be done. NSAddImage is already
>>>> deprecated, and has the side effect that images loaded with it, cannot
>>>> be unloaded. So, unload will stop working if something like this is
>>>> added in load.
>>
>>> Of course, and I'm not proposing to use the NS* API either. What I'm
>>> suggesting instead, is to record a ticket saying "dlopen(RTLD_GLOBAL)
>>> doesn't work as advertised on OSX, help!!!"
>>
>>> -Alex
>>
>> Done:https://sourceforge.net/tracker/?func=detail&aid=3033027&group_id=108...
>
> Thanks.
>
>> But I don't think a solution is probable :-)
>
> Look at the suggestion at the end of my comment there. Can you try
> this refactoring ?
>
> -Alex

No, it is not easy to do this. But in order to do this, the 3rd library
C must be in a "standard" path (or a path in LD_LIBRARY_PATH). If you
put library A also in a "standard" path, again it will work.

Imagine the following scenario: you have tclsh and the Tk dynamic
library in a non "standard" path. You load Tk in tclsh (doable with
load). Then you want to load a new Ttk theme, that is in C. You can't,
as it is linked to tk library, which is not found by dyld. (assuming of
course that pointers are not exchanged through Ttk stubs)

George
First  |  Prev  | 
Pages: 1 2 3
Prev: Creating a new method with TclOO and the C api
Next: Ariadne Designs Ltd