Re: [xslt] problems with libxslt and python on Mac OS X

[Marc-Antoine Parent <maparent acm org>]

Le 04-04-01, à 13:00, Matthew Patterson a écrit :

>
> On 1 Apr 2004, at 18:52, Marc-Antoine Parent wrote:
>
>>> What difference does that make? (I was under the impression that 
>>> having to run autogen.sh was a bad thing)
>>
>> Often, but here elements of the build process do depend on it.
>> In particular, getting the library version numbers right depends on a 
>> autogen.sh
>> As I suspect you have library version conflict, I believe in looking 
>> at that.
>
> Er, I might be missing something but both libxml and libxslt don't 
> appear to have an autogen.sh...
>
> Matt

Sorry, I realized that you may be using the source tarballs, which 
indeed do not have autogen. The process has been run for you in the 
tarballs, I believe.
I build from CVS (named tag releases, not HEAD, so I still can speak of 
precise version numbers) which has autogen.
I am a bit stumped, then...
Do me a favour: Could you at least check that the binding modules you 
built seem to bind to what you expect?

Use otool -L to know what it will link to. Example:

$  otool -L /Library/Python/2.3/libxml2mod.so
/Library/Python/2.3/libxml2mod.so:
         /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, 
current version 71.0.0)
         /usr/lib/libiconv.2.dylib (compatibility version 5.0.0, current 
version 5.0.0)
         /usr/local/lib/libxml2.2.dylib (compatibility version 9.0.0, 
current version 9.8.0)
         /System/Library/Frameworks/Python.framework/Versions/2.3/Python 
(compatibility version 2.3.0, current version 2.3.0)
$ otool -L /Library/Python/2.3/libxsltmod.so
/Library/Python/2.3/libxsltmod.so:
         /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, 
current version 71.0.0)
         /usr/lib/libz.1.dylib (compatibility version 1.0.0, current 
version 1.0.0)
         /usr/local/lib/libxslt.1.dylib (compatibility version 3.0.0, 
current version 3.5.0)
         /usr/lib/libiconv.2.dylib (compatibility version 5.0.0, current 
version 5.0.0)
         /usr/local/lib/libxml2.2.dylib (compatibility version 9.0.0, 
current version 9.8.0)
         /usr/local/lib/libexslt.0.dylib (compatibility version 9.0.0, 
current version 9.4.0)
         /System/Library/Frameworks/Python.framework/Versions/2.3/Python 
(compatibility version 2.3.0, current version 2.3.0)

Check that they are both binding to the same libxml2.2.dylib. Check 
that the libxml2.2.dylib current version (in my case 9.8.0) matches the 
library version number you expect (in my case 2.6.8)  (well, the 8 
matches! Don't ask...)
(The python framework would not be in your version of these listings, 
as you did not change the prebinding values.)

Getting the version numbers right is important, because Python pulls 
Foundation, and Foundation pulls the old /usr/lib/libxml2.lib.
So if the linker is not told that they have different version numbers, 
they will conflict.

Wait! This may why prebinding is important!
If you see nothing wrong with otool, do go through my prebinding 
instructions, just in case, because it might help the linker that the 
two versions of the library are not prebound to the same address.
If my instructions are too cryptic, try zveno's xcode packages for the 
libraries.
(I still suggest doing the full make, on the side, as it is the easiest 
way to get the bindings made. setup.py did not work so well for me, as 
I recall.)
Again, I suggest trying my build on your machine before going through 
all that trouble, in case it is compatibility with something else.
Good luck,
Marc-Antoine