[lxml-dev] install lxml 2.0.5 on Mac OS X Leopard - why is it so hard?
Kumar McMillan
kumar.mcmillan at gmail.com
Mon May 12 00:49:18 CEST 2008
Stefan, thanks for all the info
On Sun, May 11, 2008 at 2:01 AM, Stefan Behnel <stefan_ml at behnel.de> wrote:
> From my POV, Mac-OS seems to lack three things that make this problem
> non-trivial. It doesn't have a standard package management system. Neither
> does it have something like the Linux Standard Base, which dictates where
> newly installed things belong. And it doesn't seem to support "rpath", which
> would allow a binary to say "I know where my dependencies come from". Or at
> least distutils don't support that on Mac. So everything I could try here on
> Linux to make it work better is bound to fail.
I don't have experience building native OS X applications but I've
done a little more research into the problem and I think it is
specifically this:
"/usr/lib/libxml2.2.dylib uses two-level namespace, meaning that the
Foundation framework will always use this one instead of yours"
-- from http://0xced.blogspot.com/2006/07/dealing-with-outdated-open-source-libs.html
What is two-level namespacing? Good question. I haven't quite
figured that out yet but as the blog post suggests, you can "flatten"
it at runtime by setting DYLD_FORCE_FLAT_NAMESPACE=1
And, by golly, this actually works -- that is, setting it in my shell
and running my test cases that would otherwise segfault run smoothly.
Also, this doesn't screw up my lib paths like setting
DYLD_LIBRARY_PATH does (the conflict with subversion went away!).
>From more googling it does appear however that setting this var might
confuse some apps that do rely on two-level namespacing. So far *my*
problems have gone away (well, besides this being a kludge) but I
guess I'll have to keep an eye on it.
The dyld manual didn't help me understand this any better:
http://developer.apple.com/documentation/Darwin/Reference/ManPages/man1/dyld.1.html
>
> If you want this to run, let's make a deal. Here is a patch (against the
> trunk, but should work with 2.0.x) that lets --static require setting the
> STATIC_*_DIRS variables only on Windows, which should result in reading the
> directories from xml2-config/xslt-config if the hard-coded setup is not
> provided. Given your above example, this should be the right thing to do. Now,
> please look at the function "libraries()" in setupinfo.py and fix it up for
> Mac-OS-X (and for whatever sys.platform calls it) to find the correct static
> libraries in these directories. If you get it to run reliably on your system,
> just with your above command line, I'll make sure it gets into 2.0.6.
I'm willing to do whatever I can to contribute a better Mac OS X build
process for lxml. However, I'm not experienced with using ext_modules
in python and am having a hard time following your suggestions. You
say your patch removed the enforcement of STATIC_*_DIRS but that was
never a problem. in fact, that seems to confuse gcc when building
with --static since it produces orphaned -I args (no directory
attached)
Next, you suggest to adjust the sys.platform checks. sys.platform
always equals "darwin" on OS X but where would I want to make
adjustments? I don't understand what this is doing in libraries() :
if sys.platform in ('win32',):
libs = ['%s_a' % lib for lib in libs]
if I add "darwin" to the list, I get the error:
ld: library not found for -lxslt_a
whereas -lxslt is the correct arg (just like on linux). In my
/opt/local/lib dir I have libxslt.dylib, libxslt.la, libexslt.dylib,
libexslt.la, etc. I tried changing the above list comprehension to
generate .la names but that didn't work either (still said library not
found).
I'm still not clear on how to statically link the libxml libraries and
that's the first step to solving the problem. If anyone has done
this, please let me know and I'll have another go at it. Maybe I need
to use libtool to produce static versions then link to those. More
googling suggests it *is* possible ;)
http://lists.apple.com/archives/Unix-porting/2006/Aug/msg00012.html
gcc man pages are not helping me.
-Kumar
More information about the lxml-dev
mailing list