Now that I've successfully installed Cython on Windows 7, I try to compile some Cython code using Cython, but gcc makes my life hard.
cdef void say_hello(name):
print "Hello %s" % name
Using gcc to compile the code throws dozens of undefined reference to -erros, and I'm pretty sure the libpython.a is available (as the installation tutorial said, undefined reference to -errors are thrown if this file is missing).
$ cython ctest.pyx
$ gcc ctest.c -I"C:\Python27\include"
C:\Users\niklas\AppData\Local\Temp\cckThGrF.o:ctest.c:(.text+0x1038): undefined reference to `_imp__PyString_FromStringAndSize'
C:\Users\niklas\AppData\Local\Temp\cckThGrF.o:ctest.c:(.text+0x1075): undefined reference to `_imp___Py_TrueStruct'
C:\Users\niklas\AppData\Local\Temp\cckThGrF.o:ctest.c:(.text+0x1086): undefined reference to `_imp___Py_ZeroStruct'
C:\Users\niklas\AppData\Local\Temp\cckThGrF.o:ctest.c:(.text+0x1099): undefined reference to `_imp___Py_NoneStruct'
C:\Users\niklas\AppData\Local\Temp\cckThGrF.o:ctest.c:(.text+0x10b8): undefined reference to `_imp__PyObject_IsTrue'
c:/program files/mingw/bin/../lib/gcc/mingw32/4.5.2/../../../libmingw32.a(main.o):main.c:(.text+0xd2): undefined reference to `WinMain#16'
collect2: ld returned 1 exit status
The weird thing is, using pyximport* or a setup-script works pretty fine, but it's both not very handy when still working on a module.
How to compile those .c files generated with Cython using gcc ?
or any other compiler, important is that it will work !
*pyximport: Is it normal that only python-native functions and classes are contained in the imported module and not cdef-functions and classes ?
like:
# filename: cython_test.pyx
cdef c_foo():
print "c_foo !"
def foo():
print "foo !"
c_foo()
import pyximport as p; p.install()
import cython_test
cython_test.foo()
# foo !\nc_foo !
cython_test.c_foo()
# AttributeError, module object has no attribute c_foo
UPDATE
Calling $ gcc ctest.c "C:\Python27\libs\libpython27.a" kills the undefined reference to -erros, but this one:
c:/program files/mingw/bin/../lib/gcc/mingw32/4.5.2/../../../libmingw32.a(main.o):main.c:(.text+0xd2): undefined reference to `WinMain#16'
Try:
gcc -c -IC:\Python27\include -o ctest.o ctest.c
gcc -shared -LC:\Python27\libs -o ctest.pyd ctest.o -lpython27
-shared creates a shared library. -lpython27 links with the import library C:\Python27\libs\libpython27.a.
That is a linker (ld) error and not a compiler error. You should provide the path to the library (-l and -L) and not only to the headers (-I).
When I generate LLVM IR Code from C++, I can use the console command clang++ -emit-llvm –S test.cpp to get a test.ll file which is the LLVM IR I want.
To get an executable these are the steps to follow:
llvm-as test.ll -> gives me the test.bc file.
llc test.bc --o test.s -> gives me the test.s file.
clang++ test.s -o test.native -> gives me a native file that i can execute.
For C++ this works just fine.
In theory, should the same steps apply when I write Rust or Python Code?
I take my Rust code and get the LLVM IR by typing rustc test.rs --emit llvm-ir. This gives me the test.ll file again.
For Python, I use "Numba" and get the LLVM IR by typing numba --dump-llvm test.py> test.llwhich also gives me the test.ll file.
The steps to generate an executable from those .ll files should be the same.
They work up until the last step that creates the native executable:
Python Error
/tmp/test-9aa440.o: In function 'main':
test.bc:(.text+0x67): undefined reference to 'numba_gil_ensure'
test.bc:(.text+0x79): undefined reference to 'numba_unpickle'
test.bc:(.text+0x84): undefined reference to 'PyObject_Str'
test.bc:(.text+0x8f): undefined reference to 'PyString_AsString'
test.bc:(.text+0xa1): undefined reference to 'PySys_WriteStdout'
test.bc:(.text+0xa9): undefined reference to 'Py_DecRef'
test.bc:(.text+0xb1): undefined reference to 'Py_DecRef'
test.bc:(.text+0xbd): undefined reference to 'PySys_WriteStdout'
test.bc:(.text+0xc5): undefined reference to 'numba_gil_release'
test.bc:(.text+0xff): undefined reference to 'numba_gil_ensure'
test.bc:(.text+0x10b): undefined reference to 'PySys_WriteStdout'
test.bc:(.text+0x113): undefined reference to 'numba_gil_release'
clang: error: linker command failed with exit code 1 (use -v to see invocation)
Rust Error
/tmp/main-5e59bd.o: In function ‘main::sum::h514304ffa40dd7c3’:
main.bc:(.text+0xf): undefined reference to ‘core::panicking::panic::h2596388ccef1871c’
/tmp/main-5e59bd.o: In function ‘main’: main.bc:(.text+0x53): undefined reference to ‘std::rt::lang_start::h65647f6e36cffdae’
clang: error: linker command failed with exit code 1 (use -v to see invocation)
What I get from this is that clang doesn't understand the Rust/Python specific parts of the LLVM IR file (e.g. "PyObject" in Python or "panic" from Rust) that were used to generate the .bc, .s and in theory the .native files.
But why are those even in the IR in the first place? Shouldn't the LLVM IR be uniform and those parts be transformed so the LLVM toolchain can work with them?
As far as I know LLVMs modularity should allow those steps by using LLVM IR. Is there maybe another way to do this i don't know about?
Can I generate the IRs from those languages in some other way that gives "pure" LLVM IR that clang understands, or could I still generate executables from those files, but in some other way without clang?
I can speak of Rust code:
You need to link Rust's std library something like this:
$(LLI) -load /Users/Stanislaw/.rustup/toolchains/stable-x86_64-apple-darwin/lib/libstd-f5a209a9.dylib ./target/debug/jitrust.bc
See the full example of Makefile I use here.
P.S. I would assume that the same goes about Python. You have to also supply libraries which contain this "unreferenced" stuff.
I am trying to compile a Python library (CEGUI can build Python modules, its editor relies on that) that needs to link against boost-python. So I built boost, with --with-python and it built just fine.
However, as soon as the .pyd is linked, I get undefined references:
Linking CXX shared module ..\..\..\..\..\bin\PyCEGUI.pyd
CMakeFiles\PyCEGUI.dir/objects.a(AbsoluteDim.pypp.cpp.obj):AbsoluteDim.pypp.cpp:(.text+0x97): undefined reference to `_imp___ZN5boost6python7objects10class_baseC2EPKcjPKNS0_9type_infoES4_'
CMakeFiles\PyCEGUI.dir/objects.a(AbsoluteDim.pypp.cpp.obj):AbsoluteDim.pypp.cpp:(.text+0x9c): undefined reference to `_imp___ZN5boost6python9converter8registry6insertEPFPvP7_objectEPFvS5_PNS1_30rvalue_from_python_stage1_dataEENS0_9type_infoEPFPK11_typeobjectvE
'
CMakeFiles\PyCEGUI.dir/objects.a(AbsoluteDim.pypp.cpp.obj):AbsoluteDim.pypp.cpp:(.text+0xcc): undefined reference to `_imp___ZN5boost6python7objects23register_dynamic_id_auxENS0_9type_infoEPFSt4pairIPvS2_ES4_E'
CMakeFiles\PyCEGUI.dir/objects.a(AbsoluteDim.pypp.cpp.obj):AbsoluteDim.pypp.cpp:(.text+0xf4): undefined reference to `_imp___ZN5boost6python7objects8add_castENS0_9type_infoES2_PFPvS3_Eb'
CMakeFiles\PyCEGUI.dir/objects.a(AbsoluteDim.pypp.cpp.obj):AbsoluteDim.pypp.cpp:(.text+0x1cd): undefined reference to `_imp___ZN5boost6python7objects17copy_class_objectERKNS0_9type_infoES4_'
CMakeFiles\PyCEGUI.dir/objects.a(AbsoluteDim.pypp.cpp.obj):AbsoluteDim.pypp.cpp:(.text+0x20d): undefined reference to `_imp___ZN5boost6python9converter8registry6insertEPFP7_objectPKvENS0_9type_infoEPFPK11_typeobjectvE'
CMakeFiles\PyCEGUI.dir/objects.a(AbsoluteDim.pypp.cpp.obj):AbsoluteDim.pypp.cpp:(.text+0x245): undefined reference to `_imp___ZN5boost6python7objects10class_base17set_instance_sizeEj'
CMakeFiles\PyCEGUI.dir/objects.a(AbsoluteDim.pypp.cpp.obj):AbsoluteDim.pypp.cpp:(.text+0x281): undefined reference to `_imp___ZN5boost6python7objects15function_objectERKNS1_11py_functionERKSt4pairIPKNS0_6detail7keywordES9_E'
CMakeFiles\PyCEGUI.dir/objects.a(AbsoluteDim.pypp.cpp.obj):AbsoluteDim.pypp.cpp:(.text+0x2f2): undefined reference to `_imp___ZN5boost6python7objects16add_to_namespaceERKNS0_3api6objectEPKcS5_S7_'
CMakeFiles\PyCEGUI.dir/objects.a(AbsoluteDim.pypp.cpp.obj):AbsoluteDim.pypp.cpp:(.text+0x348): undefined reference to `_imp___ZN5boost6python6detail13current_scopeE'
CMakeFiles\PyCEGUI.dir/objects.a(AbsoluteDim.pypp.cpp.obj):AbsoluteDim.pypp.cpp:(.text+0x4d1): undefined reference to `_imp___ZN5boost6python9converter8registry9push_backEPFPvP7_objectEPFvS5_PNS1_30rvalue_from_python_stage1_dataEENS0_9type_infoEPFPK11_typeobjectvE'
CMakeFiles\PyCEGUI.dir/objects.a(AbsoluteDim.pypp.cpp.obj):AbsoluteDim.pypp.cpp:(.text+0x636): undefined reference to `_imp___ZN5boost6python7objects16add_to_namespaceERKNS0_3api6objectEPKcS5_'
CMakeFiles\PyCEGUI.dir/objects.a(AbsoluteDim.pypp.cpp.obj):AbsoluteDim.pypp.cpp:(.text+0x1246): undefined reference to `_imp___ZN5boost6python6detail13current_scopeE'
CMakeFiles\PyCEGUI.dir/objects.a(AbsoluteDim.pypp.cpp.obj):AbsoluteDim.pypp.cpp:(.text+0x1267): undefined reference to `_imp___ZN5boost6python6detail13current_scopeE'
c:/mingw/bin/../lib/gcc/mingw32/4.8.1/../../../../mingw32/bin/ld.exe: CMakeFiles\PyCEGUI.dir/objects.a(AbsoluteDim.pypp.cpp.obj):
bad reloc address 0x2 in section `.text$_ZN5boost6detail15sp_counted_baseD1Ev[__ZN5boost6detail15sp_counted_baseD1Ev]'
collect2.exe: error: ld returned 1 exit status
cegui\src\ScriptModules\Python\bindings\CMakeFiles\PyCEGUI.dir\build.make:6698: recipe for target 'bin/PyCEGUI.pyd' failed
mingw32-make[2]: *** [bin/PyCEGUI.pyd] Error 1
CMakeFiles\Makefile2:726: recipe for target 'cegui/src/ScriptModules/Python/bindings/CMakeFiles/PyCEGUI.dir/all' failed
mingw32-make[1]: *** [cegui/src/ScriptModules/Python/bindings/CMakeFiles/PyCEGUI.dir/all] Error 2
Makefile:135: recipe for target 'all' failed
mingw32-make: *** [all] Error 2
My first assumption was that it does not link against boost-python, but the link.txt inside the CMake folders shows this:
"C:\Coding\CMake 2.8\bin\cmake.exe" -E remove -f
CMakeFiles\PyCEGUI.dir/objects.a C:\MinGW\bin\ar.exe cr
CMakeFiles\PyCEGUI.dir/objects.a #CMakeFiles\PyCEGUI.dir\objects1.rsp
C:\MinGW\bin\g++.exe -shared -o ..........\bin\PyCEGUI.pyd
-Wl,--major-image-version,0,--minor-image-version,0 -Wl,--whole-archive CMakeFiles\PyCEGUI.dir/objects.a -Wl,--no-whole-archive ..........\lib\libCEGUIBase-0.dll.a C:\Coding\boost_1_53_0\lib\libboost_python-mgw48-mt-1_53.a
C:\Python27\libs\python27.lib
C:\Coding\CEGUI\cegui\dependencies\lib\dynamic\libfreetype.dll.a
C:\Coding\CEGUI\cegui\dependencies\lib\dynamic\libpcre.dll.a -lwinmm
-lkernel32 -luser32 -lgdi32 -lwinspool -lshell32 -lole32 -loleaut32 -luuid -lcomdlg32 -ladvapi32
So boost-python is linked against.
I am unsure what could be the problem here. Boost? CEGUI? MinGW?...
Turns out, the problem was that I was using the 64bit version of Python. I downloaded it months ago and just forgot about that little fact.
Now, MinGW can only compile and use 32 bit libraries, not mix in 64 bit. This is what led to boost-python not compiling correctly (it's a wonder it did compile at all) and thus having undefined references when linked against.
Downloading the 32bit version of Python and recompiling boost solved the problems.
So I have a few Python C extensions I have previously built for and used in 32 bit Python running in Win7. I have now however switched to 64 bit Python, and I am having issues building the C extension with MinGW-w64.
I made the changes to distutils as per this post, but I am getting some weird errors suggesting something is wrong:
$ python setup.py build
running build
running build_ext
building 'MyLib' extension
c:\MinGW64\bin\x86_64-w64-mingw32-gcc.exe -mdll -O -Wall -Ic:\Python27\lib\site-packages\numpy\core\include -Ic:\Python27\include -Ic:\Python27\PC -c MyLib.c -o build\temp.win-amd64-2.7\Release\mylib.o
MyLib.c: In function 'initMyLib':
MyLib.c:631:5: warning: implicit declaration of function 'Py_InitModule4_64' [-Wimplicit-function-declaration]
writing build\temp.win-amd64-2.7\Release\MyLib.def
c:\MinGW64\bin\x86_64-w64-mingw32-gcc.exe -shared -s build\temp.win-amd64-2.7\Release\mylib.o build\temp.win-amd64-2.7\Release\MyLib.def -Lc:\Python27\libs -Lc:\Python27\PCbuild\amd64 -lpython27 -o build\lib.win-amd64-2.7\MyLib.pyd
build\temp.win-amd64-2.7\Release\mylib.o:MyLib.c:(.text+0x13d): undefined reference to `__imp_PyExc_ValueError'
build\temp.win-amd64-2.7\Release\mylib.o:MyLib.c:(.text+0x1275): undefined reference to `__imp_PyExc_ValueError'
build\temp.win-amd64-2.7\Release\mylib.o:MyLib.c:(.text+0x1eef): undefined reference to `__imp_PyExc_ImportError'
build\temp.win-amd64-2.7\Release\mylib.o:MyLib.c:(.text+0x1f38): undefined reference to `__imp_PyExc_AttributeError'
build\temp.win-amd64-2.7\Release\mylib.o:MyLib.c:(.text+0x1f4d): undefined reference to `__imp_PyCObject_Type'
build\temp.win-amd64-2.7\Release\mylib.o:MyLib.c:(.text+0x1f61): undefined reference to `__imp_PyExc_RuntimeError'
build\temp.win-amd64-2.7\Release\mylib.o:MyLib.c:(.text+0x1fc7): undefined reference to `__imp_PyExc_RuntimeError'
build\temp.win-amd64-2.7\Release\mylib.o:MyLib.c:(.text+0x1ffe): undefined reference to `__imp_PyExc_RuntimeError'
build\temp.win-amd64-2.7\Release\mylib.o:MyLib.c:(.text+0x2042): undefined reference to `__imp_PyExc_RuntimeError'
build\temp.win-amd64-2.7\Release\mylib.o:MyLib.c:(.text+0x206c): undefined reference to `__imp_PyExc_RuntimeError'
build\temp.win-amd64-2.7\Release\mylib.o:MyLib.c:(.text+0x208a): more undefined references to `__imp_PyExc_RuntimeError' follow
build\temp.win-amd64-2.7\Release\mylib.o:MyLib.c:(.text+0x20a7): undefined reference to `__imp_PyExc_ImportError'
collect2.exe: error: ld returned 1 exit status
error: command 'x86_64-w64-mingw32-gcc' failed with exit status 1
I have googled around quite a bit to find information, but it's not easy to find a definite answer. Could someone shed some light on this? What further changes should I do to be able to successfully build C extensions for 64 bit Python in Win7?
EDIT:
After some helpful pointers in cgohlke's comments below I managed to generate libpython27.a. However after following the advice on this post (2nd to last) I still had a the __imp_Py_InitModule4_64 error. After some serious Google-fu I managed to trip over this post telling me to rename the Py_InitModule4 line to Py_InitModule4_64. After that everything worked swimmingly.
This worked for me with Python 3.3 :
create static python lib from dll
python dll is usually in C:/Windows/System32; in msys shell:
gendef.exe python33.dll
dlltool.exe --dllname python33.dll --def python33.def --output-lib libpython33.a
mv libpython33.a C:/Python33/libs
use swig to generate wrappers
e.g., swig -c++ -python myExtension.i
wrapper MUST be compiled with MS_WIN64, or your computer will crash when you import the class in Python
g++ -c myExtension.cpp -I/other/includes
g++ -DMS_WIN64 -c myExtension_wrap.cxx -IC:/Python33/include
shared library
g++ -shared -o _myExtension.pyd myExtension.o myExtension_wrap.o -lPython33 -lOtherSharedLibs -LC:/Python33/libs -LC:/path/to/other/shared/libs
make sure all shared libs (gdal, OtherSharedLibs) are in your PATH
(windows does not use LD_LIBRARY_PATH or PYTHONPATH)
in Python, just: import myExtension
voila!
I realize this is an old question, but it is still the top search result. Today, in 2019, I was able to do this:
https://github.com/PetterS/quickjs/commit/67bc2428b8c0716538b4583f4f2b0a2a5a49106c
In short:
Make sure a 64-bit version of mingw-w64 is in the PATH.
Monkey-patch distutils:
import distutils.cygwinccompiler
distutils.cygwinccompiler.get_msvcr = lambda: []
Some differences in the shell w.r.t. escaping.
extra_link_args = ["-Wl,-Bstatic", "-lpthread"] in order to link statically and not have extra runtime deps.
pipenv run python setup.py build -c mingw32 now works.
Here is a example code for VC++ Build Tools
https://github.com/starnight/python-c-extension/tree/master/00-HelloWorld
You could try:
python setup.py -c mingw32
However this is not work for me.
My Solution is:
install Anaconda 64bit python 3.6
install mingw64
add mingw64/bin to PATH
compile dll from c file by
gcc -c libmypy.c -IC:\Users\{user_name}\Anaconda3\pkgs\python-3.6.4-h6538335_1\include
gcc -shared -o libmypy.dll libmypy.o -LC:\Users\{user_name}\Anaconda3\pkgs\python-3.6.4-h6538335_1\libs -lPython36
load dll file in .py script
from ctypes import *
m = cdll.LoadLibrary(r"C:\{path_to_dll}\libmypy.dll")
print(m.hello())
I created a monkey-patch for setuptools to let you to build_ext with mingw64 on Windows easily. See https://github.com/imba-tjd/mingw64ccompiler
I used this thread to wade through learning how to make a C extension, and since most of what I learned is in it, I thought I'd put the final discovery here too, so that someone else can find it if they are looking.
I wasn't trying to compile something big, just the example in Hetland's Beginning Python. Here is what I did (the example C pgm is called palindrome.c). I'm using Anaconda with python 3.7 in it, and the TDM-GCC version of MinGW64. I put all of the tools used into my Path, and all of the paths needed in PYTHONPATH, and the ..\Anaconda3 directory into PYTHON_HOME. I still ended up using explicit paths on some things.
I created the libpython37.a library with gendef.exe and dlltool.exe as Mark said above, and put it in ..\Anaconda3\libs.
I followed the prescription in Hetland:
gcc -c palindrome.c
gcc -I$PYTHON_HOME -I$PYTHON_HOME/Include -c palindrome_wrap.c
The second failed, the compiler couldn't find Python.h, the following worked:
gcc -I[somedirectories]\Anaconda3\Include -c palindrome_wrap.c
I then did, as many have said, including Hetland 3rd ed.,
gcc -shared palindrome.o palindrome_wrap.o [somedirectories]/Anaconda3/libs/libpython37.a -o _palindrome.dll
This did not work. Even with the Load Library cswu used (which I found elsewhere, too).
So I gendef'd _palindrome.dll and couldn't find the function in it, "is_palindrome" in the exports. I went through some of the SWIG documentation, and declared the function both in the %{ %} section and below it, both extern, that finally got the function extern'd in palindrome_wrap.c as it should have been. But no export, so I went back into palindrome.c and redeclared the function as:
declspec(dllexport) extern int __stdcall is_palindrome(char* text)
and redeclared it in palindrome.i in both places as above with this signature.
Partial success! It got listed in the Export section when I gendef'd _palindrome.dll and I could do cswu's call using Load Library. But still not do what Hetland says and do
import _palindrome
in Python.
Going back to all the sources again, I could not figure this out. I finally started reading the SWIG documentation from the beginning leaving no stone unturned -- Searching through the manual doesn't produce the place found.
At the end of Introduction Sec. 2.7 Incorporating Into a Build System, under the sample Make process, it says:
"The above example will generate native build files such as makefiles, nmake files and Visual Studio projects which will invoke SWIG and compile the generated C++ files into _example.so (UNIX) or _example.pyd (Windows). For other target languages on Windows a dll, instead of a .pyd file, is usually generated."
And that's the answer to the last problem:
The compile step for the dll should read:
gcc -shared palindrome.o palindrome_wrap.o [somedirectories]/Anaconda3/libs/libpython37.a -o _palindrome.pyd
(I didn't go back and change out my declspec declarations so I don't know whether they were necessary, so they were still there too).
I got a file, _palindrome.pyd
Which if in the PYTHONPATH (mine was local) works, and one can then do
import _palindrome
from _palindrome import is_palindrome
and use the exported, properly wrapped and packaged C function, compiled with TDM-GCC, in python as promised. gcc, which is MinGW64 in a different installation, knows how to do the .pyd file. I diffed the dll and pyd since they were the same byte length. They are not the same at hundreds of points.
Hope this helps someone else.
when I launch my application with apache2+modwsgi
I catch
Exception Type: ImportError
Exception Value: DLL load failed: The specified module could not be found.
in line
from lxml import etree
with Django dev server all works fine
Visual C++ Redistributable 2008 installed
Dependency walker told that msvcrt90.dll is missed
but there is same situation with cx_Oracle, but cx_Oracle's dll loads correct
any ideas?
windows 2003 server 64bit and windows XP sp3 32bit
python 2.7 32 bit
cx_Oracle 5.0.4 32bit
UPD:
download libxml2-2.7.7 and libxslt-1.1.26
tried to build with setup.py build --compiler mingw32
Building lxml version 2.3.
Building with Cython 0.14.1.
ERROR: 'xslt-config' is not recognized as an internal or external command,
operable program or batch file.
** make sure the development packages of libxml2 and libxslt are installed **
Using build configuration of libxslt
running build
running build_py
running build_ext
skipping 'src/lxml\lxml.etree.c' Cython extension (up-to-date)
building 'lxml.etree' extension
C:\MinGW\bin\gcc.exe -mno-cygwin -mdll -O -Wall -IC:\Python27\include -IC:\Python27\PC -c src/lxml\lxml.etree.c -o build\temp.win32-2.7\Release\src\lxml\lxml.et
ree.o -w
writing build\temp.win32-2.7\Release\src\lxml\etree.def
C:\MinGW\bin\gcc.exe -mno-cygwin -shared -s build\temp.win32-2.7\Release\src\lxml\lxml.etree.o build\temp.win32-2.7\Release\src\lxml\etree.def -LC:\Python27\lib
s -LC:\Python27\PCbuild -llibxslt -llibexslt -llibxml2 -liconv -lzlib -lWS2_32 -lpython27 -lmsvcr90 -o build\lib.win32-2.7\lxml\etree.pyd
build\temp.win32-2.7\Release\src\lxml\lxml.etree.o:lxml.etree.c:(.text+0xd11): undefined reference to `_imp__xmlFree'
build\temp.win32-2.7\Release\src\lxml\lxml.etree.o:lxml.etree.c:(.text+0xd24): undefined reference to `_imp__xmlFree'
build\temp.win32-2.7\Release\src\lxml\lxml.etree.o:lxml.etree.c:(.text+0x1ee92): undefined reference to `_imp__xmlFree'
build\temp.win32-2.7\Release\src\lxml\lxml.etree.o:lxml.etree.c:(.text+0x1eed6): undefined reference to `_imp__xmlFree'
build\temp.win32-2.7\Release\src\lxml\lxml.etree.o:lxml.etree.c:(.text+0x2159e): undefined reference to `_imp__xmlMalloc'
build\temp.win32-2.7\Release\src\lxml\lxml.etree.o:lxml.etree.c:(.text+0x2e741): undefined reference to `_imp__xmlFree'
build\temp.win32-2.7\Release\src\lxml\lxml.etree.o:lxml.etree.c:(.text+0x2e784): undefined reference to `_imp__xmlFree'
build\temp.win32-2.7\Release\src\lxml\lxml.etree.o:lxml.etree.c:(.text+0x3f157): undefined reference to `_imp__xmlFree'
build\temp.win32-2.7\Release\src\lxml\lxml.etree.o:lxml.etree.c:(.text+0x3f19a): undefined reference to `_imp__xmlFree'
build\temp.win32-2.7\Release\src\lxml\lxml.etree.o:lxml.etree.c:(.text+0x3f4ac): undefined reference to `_imp__xmlFree'
build\temp.win32-2.7\Release\src\lxml\lxml.etree.o:lxml.etree.c:(.text+0x3f4ef): more undefined references to `_imp__xmlFree' follow
build\temp.win32-2.7\Release\src\lxml\lxml.etree.o:lxml.etree.c:(.text+0xb1ad5): undefined reference to `xsltLibxsltVersion'
build\temp.win32-2.7\Release\src\lxml\lxml.etree.o:lxml.etree.c:(.text+0xb1b9a): undefined reference to `xsltDocDefaultLoader'
collect2: ld returned 1 exit status
error: command 'gcc' failed with exit status 1
UPD2:
I understand why import cx_Oracle works fine: cx_Oracle.pyd contains "MSVCRT.dll" dependence etree.pyd doesn't have it
It is indeed because of 'msvcrt90.dll'. From somewhere in micro patch revisions of Python 2.6 they stopped building in automatic dependencies on the DLL for extension modules and relied on Python executable doing it. When embedded in other systems however you are then dependent on that executable linking to DLL and in the case of Apache it doesn't. The change in Python has therefore broken many systems which embed Python on Windows and the only solution is for every extension module to have their own dependencies on required DLLs which many don't. The psycopg2 extension was badly affected by this and they have change their builds to add the dependency back in themselves now. You might go searching about the problem as it occurred for psycopg2. One of the solutions was to rebuild extensions with MinGW compiler on Windows instead.