FW: [Pythonmac-SIG] Re: Compiler flags question for OSX compilation...

[Tony McDonald]

This was sent to me be Doug Landauer in Apple.

Does this help me (us :) out at all?
-- 
Dr Tony McDonald,  Assistant Director, FMCC, http://www.fmcc.org.uk/
The Medical School, Newcastle University Tel: +44 191 243 6140
A Zope list for UK HE/FE  http://www.fmcc.org.uk/mailman/listinfo/zope

------ Forwarded Message
From: Doug Landauer <landauer@apple.com>
Date: Tue, 22 May 2001 16:02:56 -0700
To: Tony McDonald <tony.mcdonald@ncl.ac.uk>
Cc: Jack Jansen <jack@oratrix.nl>
Subject: Re: [Pythonmac-SIG] Re: Compiler flags question for OSX
compilation...

On Tuesday, May 22, 2001, at 02:13 PM, Tony McDonald wrote:
> On 21/5/01 9:23 am, "Jack Jansen" <jack@oratrix.nl> wrote:
>
>> The MacOSX dynamic loader is extremely picky about symbols, and indeed
>> it
>> doesn't want a multiply defined symbol anywhere.

[Ignore if this is all old hat to you.]

I can't help with the details of the problem, but have a couple of
tidbits of general Mac OS X stuff that might conceivably help.  Many
of the projects here within Apple have run into these sorts of problems
stemming mainly from the collision between the CFM (OS 9 & earlier)
world vs the mach-o (NeXT, OS X) world.  By default, in CFM, symbols in
a shared library are private unless explicitly exported.  In mach-o,
it's the opposite.  There is an attribute, "private extern", that can
be applied to symbols in order to make them behave a little more like
the CFM ones do.

When using nm, you'll often want to use "nm -m", which is more verbose
than plain "nm" about what symbols are and what they used to be.  In
particular, after a link, "nm -m" will tell you whether a symbol was
a private extern.

With the numerous projects we've been moving from the OS 9 world, the
usual workaround that we've been using is the "nmedit" command.  This
can limit the visibility of symbols such that the sequence
     link -o foo.dylib bunch-of-objects
     nmedit -s export-list foo.dylib
behaves similar to an OS 9 link, with the given export list.

Given this, you might try running nmedit on your cDomlettec.so just
to hide its _main symbol, and run nmedit on your python executable
to hide its _XML_DefaultCurrent symbol.

(I don't think nmedit has a "just hide *this* symbol" flag, but I'll
go suggest it.)

 > (I don't think nmedit has a "just hide *this* symbol" flag, but I'll
 > go suggest it.)

Aha, it does already.

     nmedit -R filename foo.dylib

where "filename" contains the symbol(s) you wish to hide.

  -- Doug


(This will be made better and easier in a future release of Mac OS X.
Don't know which or when, though.)

Hope it helps a bit...

  -- Doug Landauer


------ End of Forwarded Message