Re: [MACTCL] tcl8.4a3 on OS X

[Jim I. <ji...@ap...>]

Daniel is right on the mark here.  I don't see any advantage to the 
bundle format, especially since it means you can't use extensions in all 
the ways Unix users (or Classic MacOS Users for that matter) are used to.

The only semi-legit reason for using the bundle format is that the 
original Mach-O loader did not allow duplicate exported symbols in two 
dylibs.  Well to be more correct if a dylib had two modules - i.e. two 
.o files - that defined the same symbol, then the two modules had to 
define the same set of symbols or dyld would throw an error and not load 
the second library.  The bundle loader doesn't mind about this, since 
you have to look up the symbols by hand to use them from outside the 
bundle.

However, this is not a problem for Tcl extensions - developers are 
pretty careful about not polluting the namespace unnecessarily, and some 
newer developments in the loader in the soon to be released 10.1 version 
will allow developers to relax this restriction and come to something 
closer to CFM or standard Unix linking behavior.

And I would like to revert to the Framework form for Tcl, but I haven't 
discussed this with Mr. Hubbard - Fred's replacement - to see what his 
feelings are about this.

Jim

On Wednesday, September 5, 2001, at 03:41  AM, Daniel A. Steffen wrote:

> At 11:33 +0200 on 5/9/01, Jack Jansen wrote:
>
>>  > two - more importantly, that sometimes tcl extension authors want to
>>>  offer the option of link against the extension libraries instead of
>>>  dynamically loading them e.g. to make available additional private
>>>  symbols in addition to the standard blah_Init and blah_SafeInit that
>>>  the dynamic loader binds.
>>
>> Ah. I now realise that I didn't tell everything. I'm building the core 
>> Python
>> as a framework bundle (giving all the advantages of easy install, 
>> etc), but
>> I'm not building the extension modules as plugin bundles. They're 
>> plain old
>> .dylib shared libs.
>>
>> The core framework bundle already gives me all the advantages I want
>> (relocatability from /Library to ~/Library by the user, 
>> self-containedness,
>> version control, sharing between various apps such as the command line 
>> tool
>> and the fullblown application, etc). Adding plugin bundles didn't seem 
>> worth
>> the effort, and indeed your message seems to indicate it's not the 
>> right way
>> to go.
>
> indeed, there is big difference between the bundle directory structure 
> and the bundle MachO binary format, they don't really have anything to 
> do with one another, except that CFBundle which abstracts the directory 
> structure can also be used to load MachO bundle code in an abstracted 
> fashion (or via CFPlugin, which is based on CFBundle), see dyld.h & 
> CFBundle.h
>
> Tcl was build as a .framework bundle directory structure at some stage 
> but later fred sanchez reverted to building tcl.dylib (along with most 
> darwin ports) in a more unix standard manner into /usr/lib to minimize 
> porting effort. I think Jim has said he'd like to move back to a 
> .framework for Tcl when Tk is done.
>
> Again this is a completely separate issue from dynamically loadable 
> binary code format, where in most cases unix legacy code probably 
> should not use the MachO bundle binary format.
>
> Cheers,
>
> Daniel
> -- ** Daniel A. Steffen          **  "And now to something completely
> ** Department of Mathematics  **   different"    Monty Python
> ** Macquarie University       ** <mailto:st...@ma...>
> ** NSW 2109 Australia         ** <http://www.maths.mq.edu.au/~steffen/>
>
> _______________________________________________
> Tcl-mac mailing list
> Tc...@li...
> https://lists.sourceforge.net/lists/listinfo/tcl-mac
>
_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-
Jim Ingham                                                           
ji...@ap...
Developer Tools - gdb