Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 23260 - Compilation of db during install gives "undefined reference to `dbopen'"
Summary: Compilation of db during install gives "undefined reference to `dbopen'"
Status: RESOLVED INVALID
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: New packages (show other bugs)
Hardware: x86 Linux
: High normal (vote)
Assignee: Gentoo Linux bug wranglers
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2003-06-22 02:52 UTC by Tim Bates
Modified: 2003-09-08 10:48 UTC (History)
0 users

See Also:
Package list:
Runtime testing required: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Tim Bates 2003-06-22 02:52:09 UTC
I'm doing a brand new install of Gentoo on a Celeron 300 with 128mb of ram. I
started with a Stage 1 only ISO from gentoo.org. I set my CFLAGS to be
"-march=pentium2 -O3 -pipe". During the compilation of glibc-2.3.1, I got
segfaults. I didn't check to see if they always occurred in the same place. At
the suggestion of someone on #gentoo (irc.freenode.net) I reduced this to -O2.
glibc-2.3.1 compiled successfully, and the bootstrap finished. I started an
`emerge system' which went as far as db, which dies with the following message:

gcc -o db_dump185  db_dump185.o  -ldb1
db_dump185.o(.text+0x11d): In function `main':
: undefined reference to `dbopen'
db_dump185.o(.text+0x157): In function `main':
: undefined reference to `dbopen'
collect2: ld returned 1 exit status
make: *** [db_dump185] Error 1

!!! ERROR: sys-libs/db-3.2.9-r2 failed.
!!! Function src_compile, Line 89, Exitcode 2
!!! Static build failed

I tried an `emerge sync'. This happened during the time that glibc-2.3.2 was
moved from ~x86 to x86. It segfaulted in strdup.c (string2.h). I didn't try a
second time to see if the segfault was consistet or random. I `emerge sync'd
again, after glibc-2.3.2 had been moved back to ~x86. db still died with the
same error. I did an `rm -rf /var/tmp/portage/db*' - still the same. Shortly
before it dies, I get this, which may or may not be relevant:

/usr/lib/gcc-lib/i686-pc-linux-gnu/3.2.2/include/g++-v3/backward/backward_warning.h:32:2:
warning: #warning This file includes at least one deprecated or antiquated
header. Please consider using one of the 32 headers found in section 17.4.1.2 of
the C++ standard. Examples include substituting the <X> header for the <X.h>
header for C++ includes, or <sstream> instead of the deprecated header
<strstream.h>. To disable this warning use -Wno-deprecated.
Comment 1 Tim Bates 2003-06-22 04:54:03 UTC
One reference to something possibly related to this problem that I can find on the 'net is:

http://www.sleepycat.com/docs/ref/build_unix/notes.html

Scroll down to the bottom, part 7. It indicates that the db-1.85 libraries have to be properly installed for this to complete. db-1.85-r1 is installed on my system, I've tried emerging it again but it doesn't seem to make any difference. During the emerge of 1.85, it gives this:

patching file recno/rec_put.c
patch: **** malformed patch at line 725: !      if (flags == R_SETCURSOR)

This may not be relevant; perhaps it should be filed as a separate bug.
Comment 2 Tim Bates 2003-06-22 18:19:38 UTC
I think there is something seriously wrong with my system. Earlier today it gave me a segfault while doing the "Updating Portage cache" part of `emerge sync' and just now it died during the configure of db, complaining that it couldn't find qsort, and I ran `emerge system' again straight away and that worked. Things goind randomly wrong is not a good state for a server to be in. I might try doing a memory test when I get home today, but if anyone could make some helpful suggestions in the meantime it would be appreciated. I'm not sure any more whether  it's worth leaving this bug open, although it's the only thing going wrong with my system that seems to be consistently reproducible so I will.
Comment 3 Tim Bates 2003-06-23 22:13:38 UTC
Okay, I did a memtest86 and it turns out one of my two memory sticks is faulty; a series of almost-consecutive words have their lowest bit stuck at 1. This probably causes misaligned memory reads for any addresses stored in those locations. I've removed that stick and extensively tested the other, and since then haven't had a problem. A clean installation has now gotten past compiling db, so it seems this was entirely related to the memory problems, despite the apparent reproducibility of the bug. Please close this bug report.
Comment 4 Martin Holzer (RETIRED) gentoo-dev 2003-09-08 10:48:29 UTC
bad memory cause this