SOLVED Problems creating extended version of Python

Guido Sohne (wgsohne@stone.princeton.edu)
Tue, 16 Aug 1994 13:56:45 GMT

>| >Guido Sohne wrote:
>| >
>| > I have been trying to create the tkinter version of Python without any
>| > success. I have succesfully built a standard and stdwin version of Python
>| > with few problems. These are the symptoms I'm coming across.
>| >
>| > After gcc -tradional compiles the source for tkinter version of python,
>| > I get a series of errors saying that libx.a (x is Python, Parser etc) is
>| > out of date and re-run ranlib.
>| >
>| > Then I get a series of errors referring to undefined symbols eg __main
>| > _newparser,_delparser among others.
>| >
>| Nope. ranlib run on each of the libraries being complained about has no
>| effect whatsoever on the problem. Guido said I should look into the way the
>| libraries are being ordered and it changed the symbols that were being
>| complained about. I think it might help me to know exactly how extensions
>| are integrated with the main package, link wise not source wise :-)
>|
>| I have only had the package for a few hours but I think the vanilla
>| intepreter is encapsulated in libModule.a libObject.a libParser.a
>| libPython.a in addition to a few other libraries like readline etc. To add
>| an extension, does one simply link in the extension.o file and the lib.a
>| generating in the compilation of the extension ? If so I could hack the
>| main python generation to just include those libraries in its link step.
>|
>| On a general note, I just can't understand how ld could not resolve all the
>| symbols if all the libraries needed are present. Thats its whole purpose. I
>| still think I'm missing something basic. Or not. If the install script
>| seems to work for everyone else but not for me it must be my fault :-)
>|
>

And indeed it was my fault :-) My system is administered by the university
computer people and sometimes things are not where they usually are. On
trying the above suggestion I found out that the tcl/tk libraries and
headers were in a completely nonstandard directory. So they werent found
and not surprisingly ld couldnt find the symbols *bonks hiimself on the
head*

The link order had something to do with not exposing the problem earlier,
previously it couldnt link to some parser internal symbols but after
shuffling the libraries, the tcl/tk symbols were the only ones not found.
That led me to go find out what symbols were being used and then to find
out that the tcl/tk files were actually not being found. gcc didnt even
peep!

Thanks to Guido for a very nice language and thanks to all of you who
replied to my message.

--
Guido Sohne





-- 

--
Guido Sohne                           EMail : wgsohne@phoenix.princeton.edu
Happy Linux user and soon to be lover/hater/basher of the OS/2 Warp II beta
Ethernet and TCP/IP for all ! Don't settle for SLIPing into the Internet !!