[Python-bugs-list] [Bug #117508] Building 2.0 under Solaris 8 with GCC 2.95.2 fails to link

[noreply@sourceforge.net]

Bug #117508, was updated on 2000-Oct-23 10:16
Here is a current snapshot of the bug.

Project: Python
Category: Build
Status: Closed
Resolution: None
Bug Group: Platform-specific
Priority: 6
Submitted by: devphil
Assigned to : david_ascher
Summary: Building 2.0 under Solaris 8 with GCC 2.95.2 fails to link

Details: With no special options to 'configure' the final link step results in

   cd Modules;  make OPT="-g -O2 -Wall -Wstrict-prototypes" VERSION="2.0" \
                   prefix="/usr/local" exec_prefix="/usr/local" \
                   LIBRARY=../libpython2.0.a link
   make[1]: Entering directory `/tmp/pedwards/newbuild/Python-2.0/Modules'
   gcc   python.o \
             ../libpython2.0.a -ldb                                 -lpthread -lsocket -lnsl -ldl  -lthread -lm  -o python 
   Undefined                       first referenced
    symbol                             in file
   dbopen                              ../libpython2.0.a(bsddbmodule.o)
   ld: fatal: Symbol referencing errors. No output written to python
   collect2: ld returned 1 exit status
   make[1]: *** [link] Error 1

This is using GNU make, and GCC with the native linker.  Using the native
compiler works fine.  



Follow-Ups:

Date: 2000-Dec-12 13:09
By: gvanrossum

Comment:
Closing. Seems to have been a unique configuration problem.
-------------------------------------------------------

Date: 2000-Oct-28 19:17
By: devphil

Comment:
Incredible.  I file a bug on Python, and end up discovering a bug in BSDDB.

There is a BSDDB locally installed...

    % ls -l /usr/local/include/db.h
    lrwxrwxrwx   1     38 Dec  7  1999 /usr/local/include/db.h -> xxx/db-2.7.7/BerkeleyDB/include/db.h
    % ls -l /usr/local/lib/libdb.a 
    lrwxrwxrwx   1     37 Dec  7  1999 /usr/local/lib/libdb.a -> xxx/db-2.7.7/BerkeleyDB/lib/libdb.a

...but they do match up, and -ldb is passed on the link line.  There is no dbopen()
in db.h, only db_open(), and that function is in the library.  The dbopen() function is
in db_185.h, but BSDDB 1.85 compatability has to be specifically enabled when building
BSDDB.  We didn't request it, because we don't need it.  So it didn't get built, and
that is correct behavior.

However, BSDDB installs db_185.h unconditionally, even if the actual implemantion is
left out of the library.  And bsddbmodule looks for db_185.h before db.h.  (This might
have been corrected; I'm looking through source from 2.7.7 which is 14 months old.)

Guess I need to tell BSDDB folks to actually *check* to see if 1.85 support was
requested by the user before installing the header.  Grrrrr...

Thanks for pointing that out.  I try to stay away from databases when possible,
and would never think on my own to look for this.


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

Date: 2000-Oct-28 03:50
By: loewis

Comment:
It appears that configure detected the presence of db.h on your system, perhaps in /usr/local. Do you have a BSDDB installation there? Could it be that this installation is somehow corrupted (e.g. that the db.h header does not match the libdb.a library?). That would explain why the native compiler has no problems - it simply doesn't see the db.h header in /usr/local, so it doesn't even attempt to build bsddbmodule.o.
-------------------------------------------------------

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