Stefan, thanks for all the info On Sun, May 11, 2008 at 2:01 AM, Stefan Behnel <stefan_ml@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.
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*
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.htm... 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!). 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...
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