Dan Eloff wrote .. > I get the following linker errors when trying to compile mod_python as > fetched from the svn tonight. > > mod_python error LNK2019: unresolved external symbol > __imp__MpFinfo_FromFinfo referenced in function _getreq_rec_fi > mod_python error LNK2019: unresolved external symbol > __imp__MpFinfo_New referenced in function _mp_stat > mod_python error LNK2019: unresolved external symbol > __imp__MpFinfo_Type referenced in function _setreq_recmbr > > The reason after some digging and coaxing the grey matter to life is > that finfoobject.c isn't added to the mod_python project. Silly of me > not to notice sooner. I don't have anything older than Visual Studio > 7, somebody else will have to fix it.
My fault. Didn't realise I had to add files into studio build file for Win32. I thought compilation there was done using Python distutils setup.py file. :-( I don't have any access to Win32 to do it if it needs VS, will have to rely on Nicolas to add it and check. > Unrelated question, is it "ok" to use the trunk in a development > environment? It will usualy work, or should I expect it to blow up in > my face more often than not? I see no reason against using the trunk for development. Except for half a dozen more minor issues that need to be cleaned up, all major work for 3.3 has been done. Personally I'd like to think it is a lot more stable than version 3.2.10 is, especially with the new importer making that aspect of things work properly. The only area I guess one may have to be careful with is if you have used PythonPath directive to extend module search path, especially if you reference directories in the document tree. This may result in mod_python complaining in the Apache error log at you and in worst case, if you have Python packages in document tree, it will not find them. If you have any issues in the area of module importing, let us know and we can step you through any required configuration tweaks. Graham
