Prev: Creating a new method with TclOO and the C api
Next: Ariadne Designs Ltd
From: Georgios Petasis on 20 Jul 2010 08:39
Στις 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.

George
From: Alexandre Ferrieux on 20 Jul 2010 12:12
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
From: Georgios Petasis on 21 Jul 2010 02:09
Στις 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.

George
From: Alexandre Ferrieux on 21 Jul 2010 02:57
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
From: Georgios Petasis on 22 Jul 2010 07:47
Στις 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=10894&atid=110894

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

Regards,

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