[Python-bugs-list] [Bug #114900] Undefined Symbols When Building

[noreply@sourceforge.net]

Bug #114900, was updated on 2000-Sep-20 10:24
Here is a current snapshot of the bug.

Project: Python
Category: Build
Status: Closed
Resolution: Wont Fix
Bug Group: Not a Bug
Priority: 1
Summary: Undefined Symbols When Building

Details: I receive the following errors when I attempt to build Python for OpenBSD 2.5:

cd Modules;  make OPT="-g -O2" VERSION="2.0"  prefix="/usr/local" exec_prefix="/usr/local"  LIBRARY=../libpython2.0.a link
gcc   python.o  ../libpython2.0.a -lreadline -ltermcap  -lc_r -lutil -lm  -o python 
main.c:115: Undefined symbol `_Py_FatalError' referenced from text segment
main.c:125: Undefined symbol `_Py_DebugFlag' referenced from text segment
main.c:130: Undefined symbol `_Py_InteractiveFlag' referenced from text segment
main.c:134: Undefined symbol `_Py_OptimizeFlag' referenced from text segment
main.c:138: Undefined symbol `_Py_NoSiteFlag' referenced from text segment
main.c:142: Undefined symbol `_Py_TabcheckFlag' referenced from text segment
main.c:150: Undefined symbol `_Py_VerboseFlag' referenced from text segment
main.c:158: Undefined symbol `_Py_UnicodeFlag' referenced from text segment
main.c:208: Undefined symbol `_Py_FdIsInteractive' referenced from text segment
main.c:232: Undefined symbol `_Py_InteractiveFlag' referenced from text segment
main.c:246: Undefined symbol `_Py_SetProgramName' referenced from text segment
main.c:247: Undefined symbol `_Py_Initialize' referenced from text segment
main.c:249: Undefined symbol `_Py_VerboseFlag' referenced from text segment
main.c:251: Undefined symbol `_Py_GetPlatform' referenced from text segment
main.c:251: Undefined symbol `_Py_GetVersion' referenced from text segment
main.c:261: Undefined symbol `_PySys_SetArgv' referenced from text segment
main.c:266: Undefined symbol `_PyImport_ImportModule' referenced from text segment
main.c:268: Undefined symbol `_PyErr_Clear' referenced from text segment
main.c:274: Undefined symbol `_PyRun_SimpleString' referenced from text segment
main.c:283: Undefined symbol `_PyRun_SimpleFile' referenced from text segment
main.c:284: Undefined symbol `_PyErr_Clear' referenced from text segment
main.c:289: Undefined symbol `_PyRun_AnyFileEx' referenced from text segment
main.c:297: Undefined symbol `_PyRun_AnyFile' referenced from text segment
main.c:299: Undefined symbol `_Py_Finalize' referenced from text segment
*** Error code 1

Stop in /home/jpettit/dev/python/dist/src/Modules.
*** Error code 1


This is with a snapshot of the CVS tree from yesterday afternoon.  I tar'd up the directory and built it under Linux fine, so I believe this is particular to OpenBSD.

Follow-Ups:

Date: 2000-Sep-20 12:55
By: loewis

Comment:
Can you check whether pythonrun.o got archived into libpython2.0.a
(ar tv libpython2.0.a), and whether Py_FatalError is exported from pythonrun.o (nm libpython2.0.a and nm pythonrun.o)?

Also, should building the library invoke ranlib on your system? Did it?
-------------------------------------------------------

Date: 2000-Sep-20 13:06
By: jpettit

Comment:
No, "pythonrun.o" was not archived into "libpython2.0.a".  When I run the "nm" command and grep for "Py_FatalError", I get the following:

    [jpettit@bastion src]$ nm libpython2.0.a |grep Py_FatalError
         U _Py_FatalError
         U _Py_FatalError
[jpettit@bastion src]$ nm Python/pythonrun.o |grep Py_FatalError
000019dc T _Py_FatalError


Yes, "ranlib" was invoked a few lines before the compiler croaked:

mv -f buildno1 buildno
gcc -c -g -O2 -I. -DHAVE_CONFIG_H -DBUILD=`cat buildno`  ./Modules/getbuildinfo.c
ar cr libpython2.0.a getbuildinfo.o
ranlib libpython2.0.a
true
cd Modules;  make OPT="-g -O2" VERSION="2.0"  prefix="/usr/local" exec_prefix="/usr/local"  LIBRARY=../libpython2.0.a link
gcc   python.o  ../libpython2.0.a -lreadline -ltermcap  -lc_r -lutil -lm  -o python 
main.c:115: Undefined symbol `_Py_FatalError' referenced from text segment
...etc, etc...
-------------------------------------------------------

Date: 2000-Sep-20 17:51
By: gvanrossum

Comment:
Could you try starting from scratch ("make clean; make")?

If pythonrun.o is not in libpython2.0.a, something's gone wrong!

What files *are* in libpython2.0.a? ("ar tf").
-------------------------------------------------------

Date: 2000-Sep-21 00:40
By: jpettit

Comment:
I've been doing a "make clean" before I try "make".  In fact, I've even been erasing "config.cache" and running "configure" before the make commands.  One of the interesting things is that when I run "make", it looks like it runs all of the "configure" checks (retrieving the cached values) twice.  I can send you the output from "make" if you like.

Here are the files in "libpython2.0.a" (there doesn't appear to be a "-f" flag for "ar" on OpenBSD):

__.SYMDEF
threadmodule.o
gcmodule.o
bsddbmodule.o
regexmodule.o
regexpr.o
pcremodule.o
pypcre.o
posixmodule.o
signalmodule.o
_sre.o
readline.o
arraymodule.o
cmathmodule.o
mathmodule.o
stropmodule.o
structmodule.o
timemodule.o
operator.o
_codecsmodule.o
unicodedata.o
unicodedatabase.o
ucnhash.o
_localemodule.o
fcntlmodule.o
pwdmodule.o
grpmodule.o
errnomodule.o
selectmodule.o
socketmodule.o
mmapmodule.o
md5module.o
md5c.o
shamodule.o
rotormodule.o
syslogmodule.o
newmodule.o
binascii.o
parsermodule.o
cStringIO.o
cPickle.o
config.o
getpath.o
main.o
getbuildinfo.o

Another thing that I noticed is that an error is raised and ignored immediately before the archive command is run:

gcc -g -O2 -I./../Include -I.. -DHAVE_CONFIG_H  -c main.c
if test -f hassignal;  then echo removing sigcheck.o intrcheck.o;  ar d ../libpython2.0.a sigcheck.o intrcheck.o 2>/dev/null;  else echo leaving sigcheck.o intrcheck.o in; fi
removing sigcheck.o intrcheck.o
*** Error code 1 (ignored)

-------------------------------------------------------

Date: 2000-Sep-21 07:18
By: gvanrossum

Comment:
That listing was a great clue! It appears that the archive only contains the *last* set of files added to it.

Can you check the man page for ar on your platform? I hope it supports adding files piecemeal -- this is what the Python build process uses.

I wonder if you change "$(AR) cr ..." to $(AR) r ..." in the add2lib target in the various sub-Makefiles -- would this fix things? That would mean that the 'c' option has a different meaning for you than it has for me. On every Unix system I've seen, 'c' just serves to suppress a warning when creating the archive. Maybe on OpenBSD it creates a new empty archive?
-------------------------------------------------------

Date: 2000-Sep-21 10:32
By: jpettit

Comment:
I think that "ar" does what you want.  Here's the man page explanation of the "-c" flag:

-c   Whenever an archive is created, an informational message to that
     effect is written to standard error.  If the -c option is speci-
     fied, ar creates the archive silently.

I was able to build Python 1.6 without any problems.  There was an issue with the "db" library on 2.0b1, but this seems to have been addressed in revision 1.145 of "configure".  The output of "make" is very strange, so I have mailed it directly to Guido, since it is probably too long to post here.  I received an auto-response, so he may want to check his public BeOpen email.
-------------------------------------------------------

Date: 2000-Sep-21 14:34
By: gvanrossum

Comment:
The best explanation I have for this is that the mtimes of various source files on his system were in the future. This caused various Make rules to trigger more than once. In the Make output he sent me, several C source files were also recompiled twice (the second time in the "add2lib" target), and he received a warning that Setup.in was newer than Setup.

Best I can tell, this has nothing to do with OpenBSD 2.5; I could reproduce this myself using rsync from a system whose clock was an hour ahead.
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=114900&group_id=5470