libxml2 issue on 10.10 beta

[Michael Dickens]

On Sat, Oct 4, 2014, at 03:28 PM, Lawrence Velázquez wrote:
> On Oct 4, 2014, at 2:47 PM, Michael Dickens <michaelld at macports.org>
> wrote:
> 
> > 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?
> 
> What does the linkage on etree.so look like?

{{{
% otool -L
/opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/lxml/etree.so
/opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/lxml/etree.so:
        /opt/local/lib/libxslt.1.dylib (compatibility version 3.0.0,
        current version 3.28.0)
        /opt/local/lib/libexslt.0.dylib (compatibility version 9.0.0,
        current version 9.17.0)
        /opt/local/lib/libxml2.2.dylib (compatibility version 12.0.0,
        current version 12.1.0)
        /opt/local/lib/libz.1.dylib (compatibility version 1.0.0,
        current version 1.2.8)
        /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current
        version 1213.0.0)
}}}

I also did, roughly:
{{{
(sudo find /opt/local -name "*.dylib or *.so" -print0 | xargs -0 otool
-L) | grep libxml2
}}}
and also included the library name when the linkage was found. I then
parsed that output & all of it looks clean.  This clearly does not
include executables, .apps, or other linked binaries.

I will admit that I did not yet parse -all- of the files in the crash
log yet to verify their linkage. I just did the most obvious suspects
plus the hammer method above. - MLD