[Python-Dev] Extension module difficulty w/pgen.

Guido van Rossum guido@python.org
Fri, 27 Sep 2002 16:24:58 -0400

> 	I know this is what I get for trying to integrate pgen into an
> extension module: I can't get it to link properly.  I first saw the
> following problem on a FreeBSD box.
> Now, I have the following two external dependencies in my extension
> module (.../src/Modules/pgenmodule.c):
> extern grammar * _Py_pgen (node * n);
> extern grammar * _Py_meta_grammar (void);
> I added an entry to setup.py for it:
>         exts.append( Extension('pgen', ['pgenmodule.c']))
> Now when I run make, the extension module is not built, with the system
> complaining about being unable to resolve "_Py_meta_grammar", but not
> "_Py_pgen".

Maybe you only get an error for the first unresolved symbol?

> When I run nm, I can see both symbols in libpython.2.3.a
> (these symbols are in pgen.c and metagrammar.c, both of which have been
> added to the libpython build target):
> ~/cvs/python/dist/src> nm ./libpython2.3.a | grep _Py_pgen
> [26]    |      2676|      48|FUNC |GLOB |0    |2      |_Py_pgen
> ~/cvs/python/dist/src> nm ./libpython2.3.a | grep _Py_meta
> [36]    |         0|      12|FUNC |GLOB |0    |2      |_Py_meta_grammar

Linux nm output looks very different, so I don't know what this
means.  Are you *sure* it doesn't mean that there are global
references but no definitions for these symbols?  And what does the 0
in the second column for _Py_meta_grammar mean?

> On the FreeBSD box, I was able to add "-L. -lpython2.3" to the command
> line, and this builds.  However, when I use this hack on a Solaris
> platform, it complains about being unable to reserve a text offset for
> most if not all of the symbols in libpython.
> It seems to me that I should not have to use this workaround, which only
> works on one of the systems I use.  Does anyone have an idea as to what I
> should do now?  I am a bit confused by this, since Fred Drake's parser
> extension does not require any of this wackiness.
> As an aside, the code for the modules I am working on and the diffs are on
> Sourceforge (PEP 269 implementation), so you can play too, if so inclined.

Maybe the problem is that nothing else uses these symbols?  Try
sticking dummy references (e.g. an unreachable call) to them in
main.c, to see if that makes a difference.  I recall we had to do this
for something else that wasn't used by Python itself.

--Guido van Rossum (home page: http://www.python.org/~guido/)