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

Guido van Rossum guido@python.org
Sat, 28 Sep 2002 19:55:26 -0400


> > > 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 Linux box.
> >
> It turns out I wasn't being thorough enough.  I used nm on my python
> build, and didn't see the symbols there.  I moved the dummy calls to
> a global function in python.c and only then were the symbols linked
> into the interpreter.
> 
> Keeping a dummy function in one of the core modules doesn't seem
> like a terribly elegant solution, even if it allows me to keep
> developing the pgen module.  What would you suggest be done to
> ensure that statically linked builds link those symbols?  I would
> assume that since the required symbols *are* in libpython (per my
> modifications to Makefile.pre.in), building a python using dynamic
> libraries would allow the extension module to "see" those symbols.

Yes, I think building a shared lib would work.  But we don't build
shared libs for all platforms.

> You had mentioned doing something like this before.  Is there some
> linkage graveyard where I can bury calls to these symbols in order
> to ensure they are linked?  Or are some of those fancy API macros
> used to ensure linkage (perhaps by API functions that are utilities
> for extension writers and not needed by the python core)?

No, AFAIK you have to create a dummy reference somewhere.  I'd suggest
adding it to the end of Python/pythonrun.c.

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