On Mon, May 12, 2008 at 4:04 AM, Stefan Behnel <stefan_ml@behnel.de> wrote:
Kumar McMillan wrote:
I don't have experience building native OS X applications
See? That seems to be a general problem amongst Mac-OS users.
Most people "use" computers they don't build them. Your work is greatly appreciated! :)
What is two-level namespacing?
*shrug*, I prefer an automatic static build on Mac-OS anyway.
me too, I think that would be the right solution.
in fact, that seems to confuse gcc when building with --static since it produces orphaned -I args (no directory attached)
It just disables the requirement for setting the variables. It doesn't configure anything so far. The config has to come from xml2-config and xslt-config.
something is going wrong then with --static because I get "Python.h not found" errors and the gcc command looked something like this: gcc ... -I -I/path/to/python/headers notice the orphaned -I call where, afaict, STATIC_INCLUDE_DIRS was previously getting inserted. Just a theory.
Hmmm, on Linux, the static libraries are called "libxml2.a" etc. Can you find anything like that on your system?
OK, I dug up some more dirt. The problem with the macport of libxml2 is that it doesn't build static libraries. From the port file itself, I now see: --disable-static, doh! But, yeah, I think if I build my own with --disable-shared and then point to that dir as an include this might work. And I assume I will probably get a libxml2.a file out of that build. But is that a feasible end user solution? That is, I'm not convinced this will make great strides in solving the lxml runtime problem where it uses the wrong version of libxml2 / libxslt. Kumar