[Pythonmac-SIG] can't link Python 2.4.1 against external libxml2 ...

[Bob Ippolito]

On Apr 3, 2005, at 23:23, OpenMacNews wrote:

>>> *something's* expecting libxml2 to be there ...
>>
>> I'll bet that it's either Cocoa or Carbon. In that case, you 
>> definitely
>> *don't* want it to use your own libxml2.
>
> makes possible sense in that there's a reference to 'Foundation', 
> which given your suspicion, refers to the OSX FoundationClass(es)? 
> I.e., Cocoa/Carbon?
>
>    >>    ld: Undefined symbols:
>    >>    _xmlSAXUserParseMemory referenced from Foundation expected to 
> be
>    >> defined in
>    >>    /usr/lib/libxml2.2.dylib
>
> thought i'd be very hard pressed to prove or disprove ...

Foundation is part of Cocoa, yes.

>> Leave it be.
>
> Which is certainly good advice if that IS the case ... yet I'm still a 
> little foggy on the whole matter given Bob's earlier comment:
>
>> either Python itself, nor any extension in the standard library, 
>> links to
> libxml.  What the heck are you talking about?
>
> which, iiuc, would suggest no dependence whatsoever on libxml -- 
> either direct or indirect via Cocoa/Carbon.

No, you don't understand correctly.  That's not what I meant.

> so, again,
>
>> Leave it be.
>
> seems to be good advice.
>
> what concerns me a bit is that 'other' apps i'm building depend on my 
> *external* libxml, and will -- eventually -- 'touch' some Python, 
> which will depend 'still' on the native (cocoa/carbon related) libxml 
> ...
>
> Will this 'version incompatibility' come back to bite me in the ass?  
> i simply dunno.
>
> short of understanding/resolving the libxml dependence i *am* seeing, 
> I guess I'll just have to wait and see when i get there =)

You are crazy!  Messing with /usr/lib or /System is just *BEGGING* to 
break your OS.  If you reboot with that libxml moved, your system might 
not even come up!

DO NOT DO THAT. EVER.

The fact that Foundation internally uses libxml is none of your 
business.

Mac OS X uses a 2 level symbol namespace, and will not have a problem 
with this, unless you use stupid linker flags like -flat_namespace.  
Python, since 2.3 (possibly in some 2.2 version as well, but I don't 
care), will not use -flat_namespace.  If you statically link to your 
external libxml, then it's impossible to have a problem, because the 
symbols aren't looked up at runtime and aren't exported to other 
modules.

-bob