hi robert,
*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 ...
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.
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 =)
thx,
richard _______________________________________________ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
