[Python-Dev] Extension module difficulty w/pgen.
Fri, 27 Sep 2002 16:20:20 -0500 (CDT)
On Fri, 27 Sep 2002, Guido van Rossum wrote:
> Maybe you only get an error for the first unresolved symbol?
Yup. When I comment out the references to _Py_meta_grammar(), it still
complains about not being able to see _Py_pgen().
> > 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
> >  | 2676| 48|FUNC |GLOB |0 |2 |_Py_pgen
> > ~/cvs/python/dist/src> nm ./libpython2.3.a | grep _Py_meta
> >  | 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?
Come on Guido, I thought you were at one point a Solaris hack ;-). FUNC
and GLOB means it is a global function defined in the module. The second
column is some sort of memory offset value, and incidently the third
column is the byte size reserved for the object (i.e. the objects should
be in the library, and are not just place holders). Here is the output
from Linux (where I have just duplicated the problem):
$ nm libpython2.3.a | egrep "_Py_(meta|pgen)"
00000000 T _Py_meta_grammar
00000e38 T _Py_pgen
If I understood the GNU info file for binutils, this means that the
symbols are defined in the text segment, and should be available for
> 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.
I tried this just now, but to no avail. Maybe I am not being thorough
enough. If the linker is excluding these symbols because they are not
used, why would nm seem to say they are there, and why would statically
linking libpython work (on FreeBSD, anyway)? Conversely, I seem to
remember this working on an earlier, but abandoned attempt I made on a
Maybe I just need more vacation. :P