Chris Perkins has saved the Mac's reputation as a development platform with his staticxml package (see the discussion on the mailinglist for paver for reference). It allows you to build lxml as a statically linked egg with little effort. As most Mac-users looking to reap the benefits of lxml will know, building this egg reliable using dynamic linking is difficult; or rather, building it is easy, getting it pick up the right libraries at run-time is a science.
There's really not much more to say. Build that egg and sleep better at night, knowing that no-one can break that sacred bond between lxml and its system library dependencies.
skip to main |
skip to sidebar
News from the testing underground
About
Hello. This blog circulates around test-driven development in Python. It's puppeteered by Malthe Borch with guest appearances by Torvald de Boskat.
2 comments:
There should be no runtime fiddling needed if you use GCC's "-rpath" flag at compile time (pointing it at the paths to the dynamic libraries you want to use). This obviates the need for "LD_LIBRARY_PATH", etc.
To my knowledge (and this is entirely based on what Stefan Eletzhofer tells me), there's no such thing as -rpath on the Mac.
And even so, static linking is attractive in a mixed environment (at least I find it very positive that I can now consistently use `lxml` in all situations).
Post a Comment