libxml2 issue on 10.10 beta

[Michael Dickens]

Yes, I know that 10.10 is not yet final. I'm also not 100% clear on what
the 10.10 beta license agreement I agreed to when installing it limits
me in saying. So, I'm going ahead anyway. :)

I do not experience this issue with libxml2 when running on 10.8 or
10.9; 10.10 is just special, somehow.  Here's the reduced info from the
crash log, in the order it appears:
{{{
Thread 0 Crashed:: Dispatch queue: com.apple.main-thread
0   libicucore.A.dylib                  0x00007fff9b5d05e3
0x7fff9b55b000 + 480739
1   libicucore.A.dylib                  0x00007fff9b5d19b7
ucnv_convertEx + 641
2   libxml2.2.dylib                     0x00007fff8f70eaf5
xmlUconvWrapper + 276
3   libxml2.2.dylib                     0x00007fff8f70f455
xmlCharEncOutput + 430
4   libxml2.2.dylib                     0x000000010fff6b9c
xmlOutputBufferFlush + 63
5   etree.so                            0x000000010fe0dc15
__pyx_f_4lxml_5etree__tostring + 725
6   etree.so                            0x000000010fe11321
__pyx_pw_4lxml_5etree_31tostring + 4721
...
       0x10fda2000 -        0x10feb6fff +etree.so (0)
       <28B36EFA-8496-32EF-B9F4-B5C9292EFD73>
       /opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/lxml/etree.so
...
       0x10ffc5000 -        0x1100bdff7 +libxml2.2.dylib (0)
       <D7C7F992-B9CC-3638-A430-E044E384C51A>
       /opt/local/lib/libxml2.2.dylib
...
    0x7fff8f6fd000 -     0x7fff8f7effff  libxml2.2.dylib (26)
    <B834E7C8-EC3E-3382-BC5A-DA38DC4D720C> /usr/lib/libxml2.2.dylib
...
    0x7fff9b55b000 -     0x7fff9b740ff3  libicucore.A.dylib (531.30)
    <EF0E7544-E317-3550-A962-6AE65E78AF17> /usr/lib/libicucore.A.dylib
}}}

So ... I think what the above tells me is that MacPorts' libxml2.2.dylib
(#4) is calling Apple's libxml2.2.dylib (#3). That's a recipe for
disaster, and it shows since this application (running in Python)
crashes in a way that I'd expect when runtime ABIs are mixed --  for
example when using the MacPorts Python executable with a Python module
linked to Apple's Python library.

Thus far, it's been pretty simple to correct this issue by recompiling
using corrected LDFLAGS or using the correct executable matching the
ABI, or the like.

In this case, it's happening -within- the library, which makes no sense
to me. The "otool -L" for both libxml2.2.dylib's is as expected. Also,
both libraries provide symbols "_xmlCharEncOutput" and
"_xmlOutputBufferFlush" ... so, there does not seem to be a need for one
library to call the other.

What am I missing?  Anybody have thoughts on other tests to determine
what's up, and/or how to correct this issue?  Thanks in advance ... -
MLD