|
Home > Archive > Apache Mod-Python > September 2006 > Fix to compile trunk on windows
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
Fix to compile trunk on windows
|
|
| Dan Eloff 2006-09-11, 1:14 am |
| 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.
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?
-Dan
| |
| Graham Dumpleton 2006-09-11, 1:14 am |
| 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
| |
| Jorey Bump 2006-09-11, 1:14 am |
| Graham Dumpleton wrote:
> 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.
Can you clarify this a bit? Does it follow that the use of PythonPath to
extend the module search path to directories *outside* of the document
tree will still be safe? I use this extensively to isolate code to
virtual hosts. I *never* include packages or modules that exist in the
document tree in PythonPath, if that's a consideration.
| |
| Graham Dumpleton 2006-09-11, 1:14 am |
| Jorey Bump wrote ..
> Graham Dumpleton wrote:
>
> used
> have
>
> Can you clarify this a bit? Does it follow that the use of PythonPath to
> extend the module search path to directories *outside* of the document
> tree will still be safe? I use this extensively to isolate code to
> virtual hosts. I *never* include packages or modules that exist in the
> document tree in PythonPath, if that's a consideration.
You can still use PythonPath for this purpose. Nothing found on PythonPath
(sys.path) will though be a candidate for automatic module reloading.
If you want any of those separate code modules to be candidates for automatic
module reloading, then rather than using PythonPath, you should set the
PythonOption mod_python.importer.path to the list of directories that the new
importer should additionally search for reloadable modules. The path should be
a full list of directories, you can't extend a list inherited from above and you
shouldn't be putting sys.path in there either.
In other words, there is a clear line between normal Python modules, which
would be found in PythonPath (sys.path) and those which are managed by the new
importer in mod_python. Standard Python modules in PythonPath (sys.path) are
still stored in sys.modules and therefore must have unique names. Those managed
by the new importer are NOT in sys.modules and are distinguished by a full
pathname such that it is possible to have modules of the same name located in
two different directories. The new importer tries to detect overlaps in the paths
and will complain when it does.
Because the new importer doesn't use sys.modules, the new importer can't look
after Python packages, as sub imports within packages only work properly if the
package is in sys.modules. As such, automatic reloading is not supported for
Python packages and thus they have to be located on PythonPath (sys.path).
There are alternate ways with the new module importer of managing package like
groupings of modules where they are a part of the web application.
Where PythonPath wasn't used, note that the directory associated with a handler
directive is no longer added to sys.path. The new module importer determines
through other means when it is necessary to search the handler directory for a
module.
The only consequence of the handler directory not being added to sys.path is
that some separate module outside of the document tree found on PythonPath
(sys.path) will no longer be able to perform a standard Python import to get
hold of a module (such as a config module) from in the handler directory.
This technique was always a bit unreliable anyway because of randomness in the
sys.path and possibility the module name may have been used in different places
with these places not being separated by using their own interpreter space.
Overall, the changes were made to support what would be considered best practice
ways of using the old importer. The new importer will complain though, by way
of messages in the Apache error log, when questionable things are being down
which could have resulted in an old application being potentially unstable. In these
cases, the application may have to be restructured in a way to avoid the questionable
practices.
The one specific case which I am sure we are most likely to see is where someone
has done:
<Directory /some/internal/path>
PythonPath "sys.path+['/some/internal/path','/some/external/path']"
PythonHandler mptest
SetHandler mod_python
</Directory>
Strictly speaking, this was probably a limitation of old importer rather than something
which was outright questionable in itself.
Anyway, they have set PythonPath because they wanted some external path to be
added to sys.path. Setting PythonPath though prevents the handler directory being
added to sys.path, so they also added that manually. In the new importer it will complain
in the Apache error logs about /some/internal/path appearing in sys.path but will
otherwise still find mptest in /some/internal/path. It will do this though because
the reloadable module will consist of that directory for the purposes of that request.
The mptest module will be reloadable and not stored in sys.modules. The problem
now comes if some module in sys.path imports mptest, because the internal path
is in sys.path, it will find it, but that will become a separate copy of the module in
memory stored in sys.modules.
The solution here in the new importer is just to say:
<Directory /some/internal/path>
PythonPath "sys.path+['/some/external/path']"
PythonHandler mptest
SetHandler mod_python
</Directory>
Ie., the internal path should not be added to sys.path. The new importer will still find
mptest in the internal path when needed by the PythonHandler directive. An external
module will no longer find mptest from the handler directory. Where obtaining
modules by a search of sys.path is done in this way, then more appropriate ways
such as passing module data down to the external module will have to be used
instead of relying on a trick like it appearing somewhere on sys.path automagically.
Graham
| |
| Nicolas Lehuen 2006-09-11, 7:12 am |
| 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 ..
>
> 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.
>
>
> 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
>
| |
| Jim Gallacher 2006-09-11, 1:12 pm |
| Dan Eloff wrote:
> 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?
At this point in the development cycle you are fairly safe. As later
messages in this thread indicate you've been caught up in a problem with
the Windows build environment rather that a mod_python bug. It's my
personal opinion that trunk should always be in a fairly stable state so
that people *can* use in their own development environment. That way we
can catch problems that may be introduced early resulting in better and
more timely releases. That being said, it is the development branch, and
breakage may happen.
Encouraging people to use trunk in their project development implies
that we have some sort of a predictable release schedule. People won't
like it if they use some new nifty feature in trunk but don't know when
it might be available in a stable release for use in production. Just
something to think about when we are planning our timelines.
Jim
| |
| Dan Eloff 2006-09-11, 1:12 pm |
| On 9/11/06, Nicolas Lehuen <nicolas@lehuen.com> wrote:
> 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.
Not your fault, probably mine for assuming the VS project was the way
to go. I'm not familiar with the dist stuff, but probably it would
work. I like to manage the compiler settings myself usually so I can
turn on optimizations. Microsoft makes a pretty good optimizing
compiler.
> 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 ?
Well I would miss it. But you can do something that would be better.
Just make a text document with some cheat notes to help people get
started building mod_python with their favourite compiler. I've
included a sample of such a file, using it as a guide, I successfully
created a new project from scratch and buuilt mod_python. You can use
it as a base.
-Dan
|
|
|
|
|