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

[Marc-Antoine Parent <maparent acm org>]

>> FYI, I tried to reproduce the problem with my install, and I do not 
>> have this problem (both tests succeed with a OK.)
>
> I didn't say exactly what I'd done:
>
> I compiled libxml2 2.6.8 and libxslt 1.1.5 from source using the 
> following invocations:
>
> libxml2:
>
> $ ./configure --with-python=/path/to/python/dir
> $ make
> $ sudo make install
>
> libxslt:
>
> $ ./configure --with-python=/path/to/python/dir 
> --with-libxml-prefix=/usr/local \
> --with-libxml-include-prefix=/usr/local/include 
> --with-libxml-libs-prefix=/usr/local/lib
> $ make
> $ sudo make install
>
> The tests produced the results I attached before.
>
> I then compiled and installed libxml2 2.6.5 and libxslt 1.1.2 over the 
> top of these using exactly the same invocations, and both tests 
> described produced 'OK'.

Strange. Your build method does not differ from mine substantially, 
except for prebindings, which should not have this kind of impact.
I am sure of that, because the crashes I described were in the 2.6.5 
timeframe.
I do strongly recommend using autogen.sh instead configure. That may be 
it right there.
BTW, how come you get your libxml in /usr/local if you do not specify 
it in the original configure? I thought /usr was the default. I may be 
wrong, but do check.

>> But there may be many differences:
>> a) I am building against Python 2.2.3 (though I also ran this on a 
>> stock Panther Python 2.3.0 install.)
>
> I built against a 2.3.3 framework python in /Library/Frameworks

Check. I was reckless enough to replace the stock Python.

>> b) When I build the bindings, I manually add instructions to the 
>> Makefiles for building with prebinding.
>
> I'm not sure I understand what you mean - I thought that prebinding 
> was something primarily associated with Cocoa apps? Can you explain 
> more

Any dylib can be prebound. It makes loading the library faster. You 
have to assign an address to each library. I use the same as Zveno's: 
http://www.zveno.com/open_source/libxml2xslt.html
Note that he has PB projects for the libraries. (Not for the bindings, 
unfortunately.)
The bindings cannot be prebound, because they are bundles, not dylibs. 
But you can at least make sure that there are no undefined symbols.

I do not like to use XCode so much, so this is how I hack the install: 
(These are notes to myself, so somewhat cryptic.)

After autoconf, in libtool
     *)
       allow_undefined=yes
becomes
     *)
       allow_undefined=no
In the Makefile: add "-Xlinker -prebind -Xlinker -seg1addr -Xlinker 
c200000" to
libxml2_la_LDFLAGS =  -version-info 8:8:6
and add  "-Xlinker -prebind" in
LDADDS =  $(top_builddir)/libxml2.la -lpthread -lz $(ICONV_LIBS) -lm
Finally, in python/Makefile, add "-Xlinker -framework -Xlinker Python" 
to
libxml2mod_la_LDFLAGS = -module -avoid-version -L$(top_builddir)/.libs

Similarly in libxslt, except that the seg1addr is c500000 for 
libxslt/Makefile, and c600000 for libexslt/Makefile
(flag names are libxslt_la_LDFLAGS = -version-info .... and  
libexslt_la_LDFLAGS = -version-info ... resp.)
and the LDADDS is in xsltproc/Makefile. Oh, and the flag in 
Python/Makefile is libxsltmod_la_LDFLAGS.)


>> I have had serious crashing problems in the past, where my Python 
>> executable would get confused between my recent libxml2 and the 
>> oldish one from Panther... I think ensuring that the library versions 
>> are correct (i.e. running the autogen.sh)
>
> Like I said above: I recompiled 1.1.2 using the same methods and got 
> vastly different results, which makes me think that it's probably not 
> that...

Well, you could have two libraries floating around and fighting.

>> I recommend that you gdb your program, and see whether the old libxml 
>> gets loaded (it is used by Foundation.framework, so it is hard to 
>> avoid.)
>
> I'm afraid that's way beyond my experience: I'm a dynamic-languages 
> only coder :(

I used to do a lot of C++, but I am becoming such a Python fan that I 
am losing the touch myself ;-)
But fair enough.

>> Also, you might want to test against my build (it contains the 
>> libraries, built in /usr/local, and the bindings)
>
> Cool, thanks - I'll have a look and see if I can figure it out!

Tell me how it goes.
Marc-Antoine