python - how can i have a static build of lxml in Unix/Linux system? -

python - how can i have a static build of lxml in Unix/Linux system? -

i have 2 unix systems, 1 service, 1 build(having environment build, yet it's old). need utilize lxml in python in service machine. next commands tried:

python setup.py build --static-deps

or

cflags="-g -o2 -fpic" python setup.py build --static-deps

but result is:

ld: fatal: relocations remain against allocatable non-writable sections collect2: ld returned 1 exit status error: command '/usr/lib/python2.6/pycc' failed exit status 1

i wondering how can create static build deploy service box?

additionally, if i

python setup.py build

it has no error, if i:

python 2.6.4 (r264:75706, apr 17 2011, 11:24:50) [c] on sunos5 type "help", "copyright", "credits" or "license" more information. >>> lxml import etree traceback (most recent phone call last): file "<stdin>", line 1, in <module> importerror: ld.so.1: isapython2.6: fatal: relocation error: file /usr/lib/python2.6/site-packages/lxml/etree.so: symbol __xmlstructurederrorcontext: referenced symbol not found

i've searched it: get errors when import lxml.etree python doesn't seem have answer. blame it's linking problem, think having statically linked should improve solution.

but main goal cut down work spent in deployment take easy ways.

please help. in advance.

the problem appears you're trying build static library without static dependencies.

a static library, libxml2.a, archive of objects (.o files). when link against this, linker copies code functions phone call out of objects link target. so, result standalone target doesn't require libxml2.a run; when phone call functions libxml2, works because code in library.

a shared library, libxml2.so, executable. when link against this, linker creates relocation entries that, when target , libxml2.so loaded memory @ same time, functions phone call out of libxml2 work, because code in libxml2.so.

what want here build hybrid: shared library (so can loaded module) dynamically links libpython.so (and maybe other things built in os), statically links in code libxml2 (and libxslt2).

a modern linker has absolutely no problem doing that—but needs static libs libxml2 that.

so, need libxml2.a (and libxslt2.a, , maybe libz.a) installed before can build want.

i've oversimplified little bit here. on platforms, .so file front-end real shared object, relocation tables plus link real file. on other platforms, code can pulled out of .so files , "relocated" in-place, , .a files can similar front-ends shared objects. , there platforms different elf terminology more misleading useful.

if want larn more, start this question , other linked , related questions there.

if don't, take on faith need .a files want statically link.

if read installation docs, you'll notice that:

on linux (and other well-behaved operating systems), pip manage build source distribution long libxml2 , libxslt installed, including development packages, i.e. header files, etc. utilize bundle management tool packages libxml2-dev or libxslt-devel if build fails, , create sure installed. alternatively, setting static_deps=true download , build both libraries automatically.

so, if don't have libraries @ all, building lxml download dependencies, build .a files you, , link against them.

but if do have them, (a) pkg-config and/or xml2-config going find them , utilize them, , (b) if doesn't, lxml may end building -lxml2 instead of absolute path libxml2.a , link wrong 1 anyway.

how can around that? well, you'd think there simple flag tell not that, far can tell, there isn't. so, options include:

build false root doesn't contain libxml2 , libxslt2. loosely hinted @ in building debian packages docs. manually build static-only libxml2 , libxslt2 , pass absolute paths resulting xml2-config , xslt2-config setup.py, explained in building sources. temporarily hack xml2-config , xslt2-config (or, if don't have those, .pc files used pkg-config) utilize absolute path .a files in ldflags, instead of -l , -l flags. temporarily .so files off library path exclusively while building lxml (by renaming them, setting different path, or otherwise). assuming version numbers (or can be) different of .so files have installed, can cheat next mac build instructions specify explicit version numbers. may have download tarballs manually work, won't have build them.

if seems kind of pain, , should easily… well, remember you're trying here. linux designed around thought of building source distributions best way possible particular system. if scheme has shared libs xml2 , xslt2, set seek utilize them. if want build code deploy scheme doesn't have those, development scheme expected not have them either; if does, you're expected know how work around that.

python unix build lxml