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 tolibxml. 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
_______________________________________________ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
