quetz-mod_python-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Nicolas Lehuen" <nico...@lehuen.com>
Subject Re: Fix to compile trunk on windows
Date Mon, 11 Sep 2006 08:41:16 GMT
Sorry I usually don't use the VS GUI to build mod_python, only the
dist/build_installer.bat script. I didn't even notice there was a VS
.vcproject file until now :). That's why I haven't noticed the problem.

In fact, I'm all in favor of dropping the VCPROJ file, because maintaining
it could promptly become a mess, what with three differents version of VS to
use (VS6 for Python 2.3, VS 2003 for Python 2.4 and who knows, VS 2005 one
day ?).

Anyone has an opinion on this ?

Regards,
Nicolas

2006/9/11, Graham Dumpleton <grahamd@dscpl.com.au>:
>
> 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
>

Mime
View raw message