[Python-bugs-list] [Bug #114900] Undefined Symbols When Building for OpenBSD 2.5
noreply@sourceforge.net
noreply@sourceforge.net
Thu, 21 Sep 2000 00:40:02 -0700
Bug #114900, was updated on 2000-Sep-20 10:24
Here is a current snapshot of the bug.
Project: Python
Category: Build
Status: Open
Resolution: None
Bug Group: Platform-specific
Priority: 5
Summary: Undefined Symbols When Building for OpenBSD 2.5
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)
-------------------------------------------------------
For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=114900&group_id=5470