f



What is the "correct" way nowadays to compile tcl extensions for OS X?

Hi all,

I have an application that has two tcl extensions in C, libA & libB.
libB depends on libA, so I load libA first, and then libB, through "load 
-global".

In general this works under windows, linux, and OS X, with one exception:

If I wrap the application with activestate's TDK, libB cannot be loaded 
under OS X. (It works for windows & linux)
It says that libA is not available, despite the fact that it has been 
loaded into the application with load -global.

So, I am thinking whether I am doing something wrong during the build 
process.

otool -hV gives for libA:

/Users/petasis/Ellogon/CDM/Darwin/x86_64/libCDM.dylib:
Mach header
       magic cputype cpusubtype  caps    filetype ncmds sizeofcmds 
flags
MH_MAGIC_64  X86_64        ALL  0x00       DYLIB    15       1824 
DYLDLINK WEAK_DEFINES BINDS_TO_WEAK NO_REEXPORTED_DYLIBS

libB gives:

/Users/petasis/Ellogon/share/modules/HTokenizer/Darwin/x86_64/libHTokenizer.dylib:
Mach header
       magic cputype cpusubtype  caps    filetype ncmds sizeofcmds 
flags
MH_MAGIC_64  X86_64        ALL  0x00       DYLIB    16       1552 
DYLDLINK NO_REEXPORTED_DYLIBS

I am not a user of OS X, but seems that both libs are build with "flat 
namespace". What are the suggested compiler flags for C extensions?

George
0
Georgios
2/5/2016 1:52:42 PM
comp.lang.tcl 23428 articles. 2 followers. Post Follow

7 Replies
447 Views

Similar Articles

[PageSpeed] 12

I think my problem is not how I have compile the libraries, but how TDK 
tclapp loads the library.

Defining DYLD_PRINT_LIBRARIES, I see loadings like:

dyld: loaded: /var/folders/22/8h57434x10z8qdhr9hd1_ymh0000gn/T/tcl_Y0DoSN

So, if the system uses the above path to get the library name, it may 
not work. I will check this, by copying libA and loading it from outside 
the wrapped executable...

George

On 5/2/2016 15:52, Georgios Petasis wrote:
> Hi all,
>
> I have an application that has two tcl extensions in C, libA & libB.
> libB depends on libA, so I load libA first, and then libB, through "load
> -global".
>
> In general this works under windows, linux, and OS X, with one exception:
>
> If I wrap the application with activestate's TDK, libB cannot be loaded
> under OS X. (It works for windows & linux)
> It says that libA is not available, despite the fact that it has been
> loaded into the application with load -global.
>
> So, I am thinking whether I am doing something wrong during the build
> process.
>
> otool -hV gives for libA:
>
> /Users/petasis/Ellogon/CDM/Darwin/x86_64/libCDM.dylib:
> Mach header
>        magic cputype cpusubtype  caps    filetype ncmds sizeofcmds flags
> MH_MAGIC_64  X86_64        ALL  0x00       DYLIB    15       1824
> DYLDLINK WEAK_DEFINES BINDS_TO_WEAK NO_REEXPORTED_DYLIBS
>
> libB gives:
>
> /Users/petasis/Ellogon/share/modules/HTokenizer/Darwin/x86_64/libHTokenizer.dylib:
>
> Mach header
>        magic cputype cpusubtype  caps    filetype ncmds sizeofcmds flags
> MH_MAGIC_64  X86_64        ALL  0x00       DYLIB    16       1552
> DYLDLINK NO_REEXPORTED_DYLIBS
>
> I am not a user of OS X, but seems that both libs are build with "flat
> namespace". What are the suggested compiler flags for C extensions?
>
> George

0
Georgios
2/5/2016 5:32:23 PM
At Fri, 5 Feb 2016 19:32:23 +0200 Georgios Petasis <petasis@iit.demokritos.gr> wrote:

> 
> I think my problem is not how I have compile the libraries, but how TDK 
> tclapp loads the library.
> 
> Defining DYLD_PRINT_LIBRARIES, I see loadings like:
> 
> dyld: loaded: /var/folders/22/8h57434x10z8qdhr9hd1_ymh0000gn/T/tcl_Y0DoSN
> 
> So, if the system uses the above path to get the library name, it may 
> not work. I will check this, by copying libA and loading it from outside 
> the wrapped executable...

Normal system I/O code cannot access anything *inside* of the StarKit.  
*Tcl's* I/O code (Tcl_Channel* API) is hooked to treat the files *inside* the 
'Kit as part of a 'mounted' file system.  The binary extension loader (Tcl's 
load command) cannot just use Tcl_Channel I/O calls (like Tcl's source 
command), it has to call the O/S's dynamic library loader (libdl under Linux, 
there is something similar under *BSD [MacOSX] and MS-Windows). This library 
knows nothing about Tcl's 'fake' mounted file system living inside of the 
'kit.  So, you need to copy the .dylib (or .so or .dll) file to someplace like 
/tmp and arange for the O/S's library loader to load from there.  I believe 
the 'kit code *re-defines* load to in fact copy the library to /tmp and then 
calls the original load function to load from /tmp.  In your case I take it 
that one of the libraries in NOT a Tcl extension, but is in fact just a 
dependent shared library for the Tcl extension library.  In that case you need 
to copy it someplace on the real file system (eg /tmp) an set up the 
environment variable(s) needed to tell the O/S's library loader to look in 
/tmp for dependent libraries.

> 
> George
> 
> On 5/2/2016 15:52, Georgios Petasis wrote:
> > Hi all,
> >
> > I have an application that has two tcl extensions in C, libA & libB.
> > libB depends on libA, so I load libA first, and then libB, through "load
> > -global".
> >
> > In general this works under windows, linux, and OS X, with one exception:
> >
> > If I wrap the application with activestate's TDK, libB cannot be loaded
> > under OS X. (It works for windows & linux)
> > It says that libA is not available, despite the fact that it has been
> > loaded into the application with load -global.
> >
> > So, I am thinking whether I am doing something wrong during the build
> > process.
> >
> > otool -hV gives for libA:
> >
> > /Users/petasis/Ellogon/CDM/Darwin/x86_64/libCDM.dylib:
> > Mach header
> >        magic cputype cpusubtype  caps    filetype ncmds sizeofcmds flags
> > MH_MAGIC_64  X86_64        ALL  0x00       DYLIB    15       1824
> > DYLDLINK WEAK_DEFINES BINDS_TO_WEAK NO_REEXPORTED_DYLIBS
> >
> > libB gives:
> >
> > /Users/petasis/Ellogon/share/modules/HTokenizer/Darwin/x86_64/libHTokenizer.dylib:
> >
> > Mach header
> >        magic cputype cpusubtype  caps    filetype ncmds sizeofcmds flags
> > MH_MAGIC_64  X86_64        ALL  0x00       DYLIB    16       1552
> > DYLDLINK NO_REEXPORTED_DYLIBS
> >
> > I am not a user of OS X, but seems that both libs are build with "flat
> > namespace". What are the suggested compiler flags for C extensions?
> >
> > George
> 
>                                                      

-- 
Robert Heller             -- 978-544-6933
Deepwoods Software        -- Custom Software Services
http://www.deepsoft.com/  -- Linux Administration Services
heller@deepsoft.com       -- Webhosting Services
                                                                                       
0
Robert
2/5/2016 7:48:46 PM
On 5/2/2016 21:48, Robert Heller wrote:
> At Fri, 5 Feb 2016 19:32:23 +0200 Georgios Petasis <petasis@iit.demokritos.gr> wrote:
>
>>
>> I think my problem is not how I have compile the libraries, but how TDK
>> tclapp loads the library.
>>
>> Defining DYLD_PRINT_LIBRARIES, I see loadings like:
>>
>> dyld: loaded: /var/folders/22/8h57434x10z8qdhr9hd1_ymh0000gn/T/tcl_Y0DoSN
>>
>> So, if the system uses the above path to get the library name, it may
>> not work. I will check this, by copying libA and loading it from outside
>> the wrapped executable...
>
> Normal system I/O code cannot access anything *inside* of the StarKit.
> *Tcl's* I/O code (Tcl_Channel* API) is hooked to treat the files *inside* the
> 'Kit as part of a 'mounted' file system.  The binary extension loader (Tcl's
> load command) cannot just use Tcl_Channel I/O calls (like Tcl's source
> command), it has to call the O/S's dynamic library loader (libdl under Linux,
> there is something similar under *BSD [MacOSX] and MS-Windows). This library
> knows nothing about Tcl's 'fake' mounted file system living inside of the
> 'kit.  So, you need to copy the .dylib (or .so or .dll) file to someplace like
> /tmp and arange for the O/S's library loader to load from there.  I believe
> the 'kit code *re-defines* load to in fact copy the library to /tmp and then
> calls the original load function to load from /tmp.  In your case I take it
> that one of the libraries in NOT a Tcl extension, but is in fact just a
> dependent shared library for the Tcl extension library.  In that case you need
> to copy it someplace on the real file system (eg /tmp) an set up the
> environment variable(s) needed to tell the O/S's library loader to look in
> /tmp for dependent libraries.

No, it is a tcl extension and not a depended library. The problem is 
that the code that automatically loads shared libraries from the vfs 
does not keep the name library. Instead of loading libFoo.so, it loads
tcl_Y0DoSN. It uses an arbitrary name when extracting the file.

So, the linker actually never sees libFoo.so, it sees tcl_Y0DoSN.

I think this is a bug, that affects tcl extensions that have 
dependencies and cannot have a stubs interface.

Of course extracting myself libFoo.dylib with a correct name, worked.

George

>
>>
>> George
>>
>> On 5/2/2016 15:52, Georgios Petasis wrote:
>>> Hi all,
>>>
>>> I have an application that has two tcl extensions in C, libA & libB.
>>> libB depends on libA, so I load libA first, and then libB, through "load
>>> -global".
>>>
>>> In general this works under windows, linux, and OS X, with one exception:
>>>
>>> If I wrap the application with activestate's TDK, libB cannot be loaded
>>> under OS X. (It works for windows & linux)
>>> It says that libA is not available, despite the fact that it has been
>>> loaded into the application with load -global.
>>>
>>> So, I am thinking whether I am doing something wrong during the build
>>> process.
>>>
>>> otool -hV gives for libA:
>>>
>>> /Users/petasis/Ellogon/CDM/Darwin/x86_64/libCDM.dylib:
>>> Mach header
>>>         magic cputype cpusubtype  caps    filetype ncmds sizeofcmds flags
>>> MH_MAGIC_64  X86_64        ALL  0x00       DYLIB    15       1824
>>> DYLDLINK WEAK_DEFINES BINDS_TO_WEAK NO_REEXPORTED_DYLIBS
>>>
>>> libB gives:
>>>
>>> /Users/petasis/Ellogon/share/modules/HTokenizer/Darwin/x86_64/libHTokenizer.dylib:
>>>
>>> Mach header
>>>         magic cputype cpusubtype  caps    filetype ncmds sizeofcmds flags
>>> MH_MAGIC_64  X86_64        ALL  0x00       DYLIB    16       1552
>>> DYLDLINK NO_REEXPORTED_DYLIBS
>>>
>>> I am not a user of OS X, but seems that both libs are build with "flat
>>> namespace". What are the suggested compiler flags for C extensions?
>>>
>>> George
>>
>>
>

0
George
2/6/2016 9:24:50 AM
At Sat, 6 Feb 2016 11:24:50 +0200 George Petasis <petasisg@yahoo.gr> wrote:

> 
> On 5/2/2016 21:48, Robert Heller wrote:
> > At Fri, 5 Feb 2016 19:32:23 +0200 Georgios Petasis <petasis@iit.demokritos.gr> wrote:
> >
> >>
> >> I think my problem is not how I have compile the libraries, but how TDK
> >> tclapp loads the library.
> >>
> >> Defining DYLD_PRINT_LIBRARIES, I see loadings like:
> >>
> >> dyld: loaded: /var/folders/22/8h57434x10z8qdhr9hd1_ymh0000gn/T/tcl_Y0DoSN
> >>
> >> So, if the system uses the above path to get the library name, it may
> >> not work. I will check this, by copying libA and loading it from outside
> >> the wrapped executable...
> >
> > Normal system I/O code cannot access anything *inside* of the StarKit.
> > *Tcl's* I/O code (Tcl_Channel* API) is hooked to treat the files *inside* the
> > 'Kit as part of a 'mounted' file system.  The binary extension loader (Tcl's
> > load command) cannot just use Tcl_Channel I/O calls (like Tcl's source
> > command), it has to call the O/S's dynamic library loader (libdl under Linux,
> > there is something similar under *BSD [MacOSX] and MS-Windows). This library
> > knows nothing about Tcl's 'fake' mounted file system living inside of the
> > 'kit.  So, you need to copy the .dylib (or .so or .dll) file to someplace like
> > /tmp and arange for the O/S's library loader to load from there.  I believe
> > the 'kit code *re-defines* load to in fact copy the library to /tmp and then
> > calls the original load function to load from /tmp.  In your case I take it
> > that one of the libraries in NOT a Tcl extension, but is in fact just a
> > dependent shared library for the Tcl extension library.  In that case you need
> > to copy it someplace on the real file system (eg /tmp) an set up the
> > environment variable(s) needed to tell the O/S's library loader to look in
> > /tmp for dependent libraries.
> 
> No, it is a tcl extension and not a depended library. The problem is 
> that the code that automatically loads shared libraries from the vfs 
> does not keep the name library. Instead of loading libFoo.so, it loads
> tcl_Y0DoSN. It uses an arbitrary name when extracting the file.

Hmmm.  What do your pkgIndex file(s) look like?  Do you have proper package 
requires and package provides?  There is load's *second* argument -- are you 
passing this second argument?  If not, then Tcl does not know the name of the 
<mumble>_Init() to call and is 'guessing' based on the name of the .so file. 

> 
> So, the linker actually never sees libFoo.so, it sees tcl_Y0DoSN.
> 
> I think this is a bug, that affects tcl extensions that have 
> dependencies and cannot have a stubs interface.

Question: are these *Tcl* level dependencies or C/C++ dependencies?  Are they 
dependencies the *linker* needs to resolve or ones resolved at the Tcl level?

> 
> Of course extracting myself libFoo.dylib with a correct name, worked.

OK, this an 'easy' fix: it is in the starkit VFS code somewhere as pure Tcl
code that replaces the built-in load function. Rather than extract the
libFoo.so file to /tmp/<random name>, it need to extract it as /tmp/libFoo.so 
instead.  The temp/random name generate step just needs to be skipped.

> 
> George
> 
> >
> >>
> >> George
> >>
> >> On 5/2/2016 15:52, Georgios Petasis wrote:
> >>> Hi all,
> >>>
> >>> I have an application that has two tcl extensions in C, libA & libB.
> >>> libB depends on libA, so I load libA first, and then libB, through "load
> >>> -global".
> >>>
> >>> In general this works under windows, linux, and OS X, with one exception:
> >>>
> >>> If I wrap the application with activestate's TDK, libB cannot be loaded
> >>> under OS X. (It works for windows & linux)
> >>> It says that libA is not available, despite the fact that it has been
> >>> loaded into the application with load -global.
> >>>
> >>> So, I am thinking whether I am doing something wrong during the build
> >>> process.
> >>>
> >>> otool -hV gives for libA:
> >>>
> >>> /Users/petasis/Ellogon/CDM/Darwin/x86_64/libCDM.dylib:
> >>> Mach header
> >>>         magic cputype cpusubtype  caps    filetype ncmds sizeofcmds flags
> >>> MH_MAGIC_64  X86_64        ALL  0x00       DYLIB    15       1824
> >>> DYLDLINK WEAK_DEFINES BINDS_TO_WEAK NO_REEXPORTED_DYLIBS
> >>>
> >>> libB gives:
> >>>
> >>> /Users/petasis/Ellogon/share/modules/HTokenizer/Darwin/x86_64/libHTokenizer.dylib:
> >>>
> >>> Mach header
> >>>         magic cputype cpusubtype  caps    filetype ncmds sizeofcmds flags
> >>> MH_MAGIC_64  X86_64        ALL  0x00       DYLIB    16       1552
> >>> DYLDLINK NO_REEXPORTED_DYLIBS
> >>>
> >>> I am not a user of OS X, but seems that both libs are build with "flat
> >>> namespace". What are the suggested compiler flags for C extensions?
> >>>
> >>> George
> >>
> >>
> >
> 
>                                                                        

-- 
Robert Heller             -- 978-544-6933
Deepwoods Software        -- Custom Software Services
http://www.deepsoft.com/  -- Linux Administration Services
heller@deepsoft.com       -- Webhosting Services
 
0
Robert
2/6/2016 12:37:49 PM
On 6/2/2016 14:37, Robert Heller wrote:
> At Sat, 6 Feb 2016 11:24:50 +0200 George Petasis <petasisg@yahoo.gr> wrote:
>
>>
>> On 5/2/2016 21:48, Robert Heller wrote:
>>> At Fri, 5 Feb 2016 19:32:23 +0200 Georgios Petasis <petasis@iit.demokritos.gr> wrote:
>>>
>>>>
>>>> I think my problem is not how I have compile the libraries, but how TDK
>>>> tclapp loads the library.
>>>>
>>>> Defining DYLD_PRINT_LIBRARIES, I see loadings like:
>>>>
>>>> dyld: loaded: /var/folders/22/8h57434x10z8qdhr9hd1_ymh0000gn/T/tcl_Y0DoSN
>>>>
>>>> So, if the system uses the above path to get the library name, it may
>>>> not work. I will check this, by copying libA and loading it from outside
>>>> the wrapped executable...
>>>
>>> Normal system I/O code cannot access anything *inside* of the StarKit.
>>> *Tcl's* I/O code (Tcl_Channel* API) is hooked to treat the files *inside* the
>>> 'Kit as part of a 'mounted' file system.  The binary extension loader (Tcl's
>>> load command) cannot just use Tcl_Channel I/O calls (like Tcl's source
>>> command), it has to call the O/S's dynamic library loader (libdl under Linux,
>>> there is something similar under *BSD [MacOSX] and MS-Windows). This library
>>> knows nothing about Tcl's 'fake' mounted file system living inside of the
>>> 'kit.  So, you need to copy the .dylib (or .so or .dll) file to someplace like
>>> /tmp and arange for the O/S's library loader to load from there.  I believe
>>> the 'kit code *re-defines* load to in fact copy the library to /tmp and then
>>> calls the original load function to load from /tmp.  In your case I take it
>>> that one of the libraries in NOT a Tcl extension, but is in fact just a
>>> dependent shared library for the Tcl extension library.  In that case you need
>>> to copy it someplace on the real file system (eg /tmp) an set up the
>>> environment variable(s) needed to tell the O/S's library loader to look in
>>> /tmp for dependent libraries.
>>
>> No, it is a tcl extension and not a depended library. The problem is
>> that the code that automatically loads shared libraries from the vfs
>> does not keep the name library. Instead of loading libFoo.so, it loads
>> tcl_Y0DoSN. It uses an arbitrary name when extracting the file.
>
> Hmmm.  What do your pkgIndex file(s) look like?  Do you have proper package
> requires and package provides?  There is load's *second* argument -- are you
> passing this second argument?  If not, then Tcl does not know the name of the
> <mumble>_Init() to call and is 'guessing' based on the name of the .so file.

The problem is not in loading the library. The library gets loaded fine.
It provides a tcl interface, but also functions for other plugins.
It is the plugins that cannot be loaded. The os loader does not know it 
has loaded libfoo.dylib, as it was loaded under another mangled name.

So, loading libx.dylib, that depends on libfoo.dylib, fails. Because 
libfoo.dylib cannot be found, despite the fact that it has already been 
loaded into the application.


>
>>
>> So, the linker actually never sees libFoo.so, it sees tcl_Y0DoSN.
>>
>> I think this is a bug, that affects tcl extensions that have
>> dependencies and cannot have a stubs interface.
>
> Question: are these *Tcl* level dependencies or C/C++ dependencies?  Are they
> dependencies the *linker* needs to resolve or ones resolved at the Tcl level?

Yes, they are C++ dependencies. The fact that tclapp loads the libraries 
under arbitrary names, breaks these dependencies.

George
>
>>
>> Of course extracting myself libFoo.dylib with a correct name, worked.
>
> OK, this an 'easy' fix: it is in the starkit VFS code somewhere as pure Tcl
> code that replaces the built-in load function. Rather than extract the
> libFoo.so file to /tmp/<random name>, it need to extract it as /tmp/libFoo.so
> instead.  The temp/random name generate step just needs to be skipped.
>
>>
>> George
>>
>>>
>>>>
>>>> George
>>>>
>>>> On 5/2/2016 15:52, Georgios Petasis wrote:
>>>>> Hi all,
>>>>>
>>>>> I have an application that has two tcl extensions in C, libA & libB.
>>>>> libB depends on libA, so I load libA first, and then libB, through "load
>>>>> -global".
>>>>>
>>>>> In general this works under windows, linux, and OS X, with one exception:
>>>>>
>>>>> If I wrap the application with activestate's TDK, libB cannot be loaded
>>>>> under OS X. (It works for windows & linux)
>>>>> It says that libA is not available, despite the fact that it has been
>>>>> loaded into the application with load -global.
>>>>>
>>>>> So, I am thinking whether I am doing something wrong during the build
>>>>> process.
>>>>>
>>>>> otool -hV gives for libA:
>>>>>
>>>>> /Users/petasis/Ellogon/CDM/Darwin/x86_64/libCDM.dylib:
>>>>> Mach header
>>>>>          magic cputype cpusubtype  caps    filetype ncmds sizeofcmds flags
>>>>> MH_MAGIC_64  X86_64        ALL  0x00       DYLIB    15       1824
>>>>> DYLDLINK WEAK_DEFINES BINDS_TO_WEAK NO_REEXPORTED_DYLIBS
>>>>>
>>>>> libB gives:
>>>>>
>>>>> /Users/petasis/Ellogon/share/modules/HTokenizer/Darwin/x86_64/libHTokenizer.dylib:
>>>>>
>>>>> Mach header
>>>>>          magic cputype cpusubtype  caps    filetype ncmds sizeofcmds flags
>>>>> MH_MAGIC_64  X86_64        ALL  0x00       DYLIB    16       1552
>>>>> DYLDLINK NO_REEXPORTED_DYLIBS
>>>>>
>>>>> I am not a user of OS X, but seems that both libs are build with "flat
>>>>> namespace". What are the suggested compiler flags for C extensions?
>>>>>
>>>>> George
>>>>
>>>>
>>>
>>
>>
>

0
Georgios
2/6/2016 5:18:13 PM
At Sat, 6 Feb 2016 19:18:13 +0200 Georgios Petasis <petasis@iit.demokritos.gr> wrote:

> 
> On 6/2/2016 14:37, Robert Heller wrote:
> > At Sat, 6 Feb 2016 11:24:50 +0200 George Petasis <petasisg@yahoo.gr> wrote:
> >
> >>
> >> On 5/2/2016 21:48, Robert Heller wrote:
> >>> At Fri, 5 Feb 2016 19:32:23 +0200 Georgios Petasis <petasis@iit.demokritos.gr> wrote:
> >>>
> >>>>
> >>>> I think my problem is not how I have compile the libraries, but how TDK
> >>>> tclapp loads the library.
> >>>>
> >>>> Defining DYLD_PRINT_LIBRARIES, I see loadings like:
> >>>>
> >>>> dyld: loaded: /var/folders/22/8h57434x10z8qdhr9hd1_ymh0000gn/T/tcl_Y0DoSN
> >>>>
> >>>> So, if the system uses the above path to get the library name, it may
> >>>> not work. I will check this, by copying libA and loading it from outside
> >>>> the wrapped executable...
> >>>
> >>> Normal system I/O code cannot access anything *inside* of the StarKit.
> >>> *Tcl's* I/O code (Tcl_Channel* API) is hooked to treat the files *inside* the
> >>> 'Kit as part of a 'mounted' file system.  The binary extension loader (Tcl's
> >>> load command) cannot just use Tcl_Channel I/O calls (like Tcl's source
> >>> command), it has to call the O/S's dynamic library loader (libdl under Linux,
> >>> there is something similar under *BSD [MacOSX] and MS-Windows). This library
> >>> knows nothing about Tcl's 'fake' mounted file system living inside of the
> >>> 'kit.  So, you need to copy the .dylib (or .so or .dll) file to someplace like
> >>> /tmp and arange for the O/S's library loader to load from there.  I believe
> >>> the 'kit code *re-defines* load to in fact copy the library to /tmp and then
> >>> calls the original load function to load from /tmp.  In your case I take it
> >>> that one of the libraries in NOT a Tcl extension, but is in fact just a
> >>> dependent shared library for the Tcl extension library.  In that case you need
> >>> to copy it someplace on the real file system (eg /tmp) an set up the
> >>> environment variable(s) needed to tell the O/S's library loader to look in
> >>> /tmp for dependent libraries.
> >>
> >> No, it is a tcl extension and not a depended library. The problem is
> >> that the code that automatically loads shared libraries from the vfs
> >> does not keep the name library. Instead of loading libFoo.so, it loads
> >> tcl_Y0DoSN. It uses an arbitrary name when extracting the file.
> >
> > Hmmm.  What do your pkgIndex file(s) look like?  Do you have proper package
> > requires and package provides?  There is load's *second* argument -- are you
> > passing this second argument?  If not, then Tcl does not know the name of the
> > <mumble>_Init() to call and is 'guessing' based on the name of the .so file.
> 
> The problem is not in loading the library. The library gets loaded fine.
> It provides a tcl interface, but also functions for other plugins.
> It is the plugins that cannot be loaded. The os loader does not know it 
> has loaded libfoo.dylib, as it was loaded under another mangled name.
> 
> So, loading libx.dylib, that depends on libfoo.dylib, fails. Because 
> libfoo.dylib cannot be found, despite the fact that it has already been 
> loaded into the application.

OK, so it is *BOTH* a Tcl extension AND a dependent library.

It *actually* sounds like a bug with the MacOSX/Darwin/*BSD library system.  
Generally, shared library files have headers that define the library's 
internal structure, including the library's link name and all of the symbols 
it defines.  At least this is what *modern* libraries do.  The library loader 
should update the table of loaded libraries and the symbols they provide.  
This seems to not be happening under MacOSX...


> 
> 
> >
> >>
> >> So, the linker actually never sees libFoo.so, it sees tcl_Y0DoSN.
> >>
> >> I think this is a bug, that affects tcl extensions that have
> >> dependencies and cannot have a stubs interface.
> >
> > Question: are these *Tcl* level dependencies or C/C++ dependencies?  Are they
> > dependencies the *linker* needs to resolve or ones resolved at the Tcl level?
> 
> Yes, they are C++ dependencies. The fact that tclapp loads the libraries 
> under arbitrary names, breaks these dependencies.
> 
> George
> >
> >>
> >> Of course extracting myself libFoo.dylib with a correct name, worked.
> >
> > OK, this an 'easy' fix: it is in the starkit VFS code somewhere as pure Tcl
> > code that replaces the built-in load function. Rather than extract the
> > libFoo.so file to /tmp/<random name>, it need to extract it as /tmp/libFoo.so
> > instead.  The temp/random name generate step just needs to be skipped.
> >
> >>
> >> George
> >>
> >>>
> >>>>
> >>>> George
> >>>>
> >>>> On 5/2/2016 15:52, Georgios Petasis wrote:
> >>>>> Hi all,
> >>>>>
> >>>>> I have an application that has two tcl extensions in C, libA & libB.
> >>>>> libB depends on libA, so I load libA first, and then libB, through "load
> >>>>> -global".
> >>>>>
> >>>>> In general this works under windows, linux, and OS X, with one exception:
> >>>>>
> >>>>> If I wrap the application with activestate's TDK, libB cannot be loaded
> >>>>> under OS X. (It works for windows & linux)
> >>>>> It says that libA is not available, despite the fact that it has been
> >>>>> loaded into the application with load -global.
> >>>>>
> >>>>> So, I am thinking whether I am doing something wrong during the build
> >>>>> process.
> >>>>>
> >>>>> otool -hV gives for libA:
> >>>>>
> >>>>> /Users/petasis/Ellogon/CDM/Darwin/x86_64/libCDM.dylib:
> >>>>> Mach header
> >>>>>          magic cputype cpusubtype  caps    filetype ncmds sizeofcmds flags
> >>>>> MH_MAGIC_64  X86_64        ALL  0x00       DYLIB    15       1824
> >>>>> DYLDLINK WEAK_DEFINES BINDS_TO_WEAK NO_REEXPORTED_DYLIBS
> >>>>>
> >>>>> libB gives:
> >>>>>
> >>>>> /Users/petasis/Ellogon/share/modules/HTokenizer/Darwin/x86_64/libHTokenizer.dylib:
> >>>>>
> >>>>> Mach header
> >>>>>          magic cputype cpusubtype  caps    filetype ncmds sizeofcmds flags
> >>>>> MH_MAGIC_64  X86_64        ALL  0x00       DYLIB    16       1552
> >>>>> DYLDLINK NO_REEXPORTED_DYLIBS
> >>>>>
> >>>>> I am not a user of OS X, but seems that both libs are build with "flat
> >>>>> namespace". What are the suggested compiler flags for C extensions?
> >>>>>
> >>>>> George
> >>>>
> >>>>
> >>>
> >>
> >>
> >
> 
>                                                                                        

-- 
Robert Heller             -- 978-544-6933
Deepwoods Software        -- Custom Software Services
http://www.deepsoft.com/  -- Linux Administration Services
heller@deepsoft.com       -- Webhosting Services
                             
0
Robert
2/6/2016 8:50:36 PM
On 6/2/2016 22:50, Robert Heller wrote:
>
> OK, so it is *BOTH* a Tcl extension AND a dependent library.
>
Yes, it is.

> It *actually* sounds like a bug with the MacOSX/Darwin/*BSD library system.
> Generally, shared library files have headers that define the library's
> internal structure, including the library's link name and all of the symbols
> it defines.  At least this is what *modern* libraries do.  The library loader
> should update the table of loaded libraries and the symbols they provide.
> This seems to not be happening under MacOSX...
>
I also think it is happening. Is it because I have used "flat 
namespaces"? I really don't know, but extracting it under a correct 
filename, seems to have fixed the problem, at least for now...

George
0
Georgios
2/6/2016 9:50:13 PM
Reply:

Similar Artilces:

Ann: Tcl/Tk "Universal" packages for Mac OS X
I've packaged "universal" installers of Tcl/Tk for Mac OS X (both the Aqua and X11 variants), and the Tile theming extension, for use on Mac OS X's PPC and Intel architectures. These builds are based on Tcl/Tk 8.4.13. Downloads and more information can be found at http://tk-components.sourceforge.net/installer/ Thanks. -- Kevin Walzer Poetic Code http://www.kevin-walzer.com ...

""""""""""""""""""""""ADD ME""""""""""""""""""""
Hi , Hope you are doing great. Please let me take this opportunity to introduce myself, Iam Karthik working with BhanInfo Inc, a NY based company. We have consultants on our bench on various technologies, my request is to add me to your distribution list and kindly do send me the requirements. i have the below list available 1. Mainframe 2. Java 3.. Financial Analyst 4. Data Architect If there is any vendor ship agreement which has to be signed then I would like to take an opportunity to represent my company and expect your cooperation... We look forward to build a ve...

Relationship to "X" or not to "X"...
TABLES: Parent p_id order info Child p_iD f_id transaction info RELATIONSHIP parent::p_id = child::f_id Scripted button creates a new child record and passes the parent::p_id to the child::f_id This works fine, and when changing views to the child layout - everything is there and in the correct places. However, the portal I have on the parent table (showing child fields) is blank - shows no lines. If I change the relationship to: parent::p_id X child::f_id the portal instantly shows all transactions regardless of the order id, not just those of the parent::p_id order...

"""""""""ADD ME""""""""""
Hi , Hope you are doing great. Please let me take this opportunity to introduce myself, Iam Karthik working with BhanInfoi Inc, a NY based company. We have consultants on our bench on various technologies, my request is to add me to your distribution list and kindly do send me the requirements. i have the below list available 1. Mainframe 2. Java 3.. Financial Analyst 4. Data Architect If there is any vendor ship agreement which has to be signed then I would like to take an opportunity to represent my company and expect your cooperation... ...

ANN: Tcl-Tk-Aqua 8.4.14 "universal" installer for OS X
The Tcl/Tk "Universal" packages are distributions of the core Tcl/Tk libraries, plus the Tile theming extension, built to support the PPC and Intel architectures of the Mac OS X platforms. They can be downlaoded at http://tk-components.sourceforge.net/installer/index.html. OVERVIEW OF PACKAGES The Tcl/Tk "Universal" package for Mac OS X are based on the current version of Tcl/Tk at the time of this build, 8.4.14. The Tile extension is version 0.7.8. The packages support the native Aqua version. Aqua The "Aqua" package supports the native Mac windowing env...

Fve Ver5.1 (Editor for "Mac OS X"/Cygwin/Unix/Windows)Tcl/Tk_script
Fve Ver5.1 (Editor for "Mac OS X"/Cygwin/Unix/Windows)Tcl/Tk_script (File Viewer Editor_Version Fve 5.1) http://www.ne.jp/asahi/kazuo/sasagawa/ For Tcl/Tk 8.4: TclTkAqua 8.4: Tcl/Tk-cygwin 8.4. Please use ActiveTcl 8.4.14 binary packages or "TclTkAqua 8.4.10 binary packages". *Changes(Version5.1) 1 Added a "Specify a set of tab stops" item to Options_Menu. 2 Added a "exec acroread" item to "Options_Menu -> pdf file". (Mac) 3 Added a "hex dump -> use HexEditor" item to Options_Menu. (Mac) 4 Added a "I...

Fve Ver5.5 (Editor for "Mac OS X"/Unix/Windows) Tcl/Tk script
Fve Ver5.5 (Editor for "Mac OS X"/Unix/Windows) Tcl/Tk script (File_Viewer Editor Version -- Fve Ver5.5) http://www.ne.jp/asahi/kazuo/sasagawa/ For Tcl/Tk 8.4,8.5,8.6: *Changes(Version5.5) 1 Modify the Help file. 2 Added "chmod" Button. (Copy Files...) 3 Added "delete the beginning of a line" item. ("Copy Files..." --> "rename files" MenuButton) 4 Change the startup file name (Mac OS X). $root/_fve/.fverc -> $root/_fve/_fverc <Mac OS X> *** 1. In 2015-6-10 latest Tcl/Tk8.5.18,8.6.4, it...

Unable to understand "uplevel" and "upvar" in TCL
Hi, I have never been able to understand "uplevel" and "upvar" in TCL and when to use them? Can anyone explain this to me in a way that I can understand, with examples please? Thanks, Ahmed Ahmed Omara wrote: > Hi, > > I have never been able to understand "uplevel" and "upvar" in TCL and > when to use them? > > Can anyone explain this to me in a way that I can understand, with > examples please? They are highly useful when implementing your own control structures, but it's not limited to. They make m...

OS X "Created" vs "Modified"
Am I missing something, here? Does OS X only show the date a file was originally created, instead of last modified? Is there a setting or something I just can't find? TIA KCP In article <powell_on_tour-89615D.15412516032005@news.sentex.ca>, K P <powell_on_tour@hotmail.com> wrote: > Am I missing something, here? Does OS X only show the date a file was > originally created, instead of last modified? Is there a setting or > something I just can't find? > > TIA > > KCP Found it. Should have looked under "View Options" first. Blam...

ANN:Fve Ver5.2 (Editor for "Mac OS X"/Cygwin/Unix/Windows) Tcl/Tk script
Fve Ver5.2 (Editor for "Mac OS X"/Cygwin/Unix/Windows) Tcl/Tk script (File Viewer Editor_Version Fve 5.2) http://www.ne.jp/asahi/kazuo/sasagawa/ For Tcl/Tk 8.4,8.5: TclTkAqua 8.4: Tcl/Tk-cygwin 8.4. Please use ActiveTcl 8.4.18 binary packages or "TclTkAqua 8.4.10 binary packages". *Changes(Version5.2) 1 Added a "Customizing key bingings" item to Tools_Menu. 2 Added several bindings for Mac OS X. Command-a -> Select all Command-c -> Copy Command-e -> Use Selection for Find Command-f -> Find Command-g -> Find Next Command-i -...

Urgent Requirement in """""""""""""NEW YORK""""""""""""""""
Hello Partners, Please find the requirement below. Please send the updated resume along with rate and contact no. REQ#1: Title : Java Developer ( Rating Project) Duration : 6 months Rate : open Location : NY strong java, WebLogic 9.2, Web Services, Oracle REQ#2: Title : Java Developer Duration : 4 months Rate : open Location : NY Strong java, SQL REQ#3: Title : VB.Net Consultant Location : NY Duration : 4 months Rate : open Primarily looking at someone who has Excel, VB.net a...

"my" and "our"
Hi, while testing a program, I erroneously declared the same variable twice within a block, the first time with "my", the second time with "our": { my $fz = 'VTX_Link'; .... ( around 200 lines of code, all in the same block) our $fz = 'VTX_Linkset'; ... } So the initial contents of the $fz declared with "my" is lost, because "our" creates a lexical alias for the global $fz, thus overwriting the previous "my" declaration. It was my error, no question. But I wonder why Perl doesn't mention this - even with "use s...

"out" and "in out"
Hi i found the following explaination: In Ada, "in" parameters are similar to C++ const parameters. They are effectively read-only within the scope of the called subprogram. Ada "in out" parameters have a reliable initial value (that passed in from the calling subprogram) and may be modified within the scope of the called procedure. Ada "out" parameters have no reliable initial value, but are expected to be assigned a value within the called procedure. What does "have no reliable initial value" mean when considering the "out" parameter? By c...

"If then; if then;" and "If then; if;"
I have a raw data set which is a hierarchical file: H 321 s. main st P Mary E 21 F P william m 23 M P Susan K 3 F H 324 S. Main St I use the folowing code to read the data to creat one observation per detail(P) record including hearder record(H): data test; infile 'C:\Documents and Settings\retain.txt'; retain Address; input type $1. @; if type='H' then input @3 Address $12.; if type='P' then input @3 Name $10. @13 Age 3. @16 Gender $1.; run; but the output is not what I want: 1 321 s. main H 2 321 s. main P Mary E 21 F 3 321 s...

Web resources about - What is the "correct" way nowadays to compile tcl extensions for OS X? - comp.lang.tcl

Resources last updated: 2/6/2016 1:11:57 PM