Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 47485 - libc appears to be missing vital function (__divsi3)
Summary: libc appears to be missing vital function (__divsi3)
Status: RESOLVED NEEDINFO
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: [OLD] Core system (show other bugs)
Hardware: IA64 Linux
: High blocker (vote)
Assignee: IA-64 team
URL:
Whiteboard:
Keywords:
Depends on: 60190
Blocks:
  Show dependency tree
 
Reported: 2004-04-10 23:34 UTC by Duraid Madina
Modified: 2004-09-07 15:21 UTC (History)
1 user (show)

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 Duraid Madina 2004-04-10 23:34:11 UTC
I keep my system relatively "up to date". While trying to debug a GTK problem (completely unrelated to this bug), I went ahead and rebuilt GTK (sitting in my home directory). I tried to run vim to edit some code and, to my surprise, I got this:

/home/duraid/garnome/lib/libgtk-x11-2.0.so.0: undefined symbol: __divsi3

It's since gone downhill from there. Almost anything that was compiled more recently (it must have been a glibc/gcc upgrade I performed some time ago and just didn't notice at the time, I normally work with the Intel C++ compiler every day) has this same error, not just GTK.

OK, the first bit of good news. There's a fairly easy fix. If I create a file /etc/ld.so.preload , so that it contains the single entry:

/usr/lib/gcc-lib/ia64-unknown-linux-gnu/3.3.2/libgcc_s.so.1

Then everything works again! The __divsi3 function (integer division support I am guessing, as IA64 doesn't have divide in hardware) is defined in this libgcc_s.so file.

However, I've spent hours trying to repair my system so that this workaround isn't required. I am going to go out on a limb here, and _guess_ that this function should be defined in glibc, not libgcc. Either that, or GCC should be spitting this function into every binary it produces, not keeping it in a shared library. The problem, of course, is that binaries which GCC produces don't actually _attempt_ to dynamically link to libgcc_s. They just fail with this undefined symbol error.

Please help! I'm not so concerned about *how* this happened as to how to get out if it a little more elegantly than by using the ld.so.preload hack (if only because that will probably fail in interesting ways if and when I upgrade to GCC 3.4, which has some BIG improvements on IA64).

For the record, I have backed down my glibc (just slightly) to the latest stable versions on ia64: 2.3.2-r9 and 3.3.2-r2, but this doesn't seem to change a thing.)


Reproducible: Always
Steps to Reproduce:
1.
2.
3.
Comment 1 SpanKY gentoo-dev 2004-08-15 22:46:06 UTC
glibc should not provide that symbol, libgcc should

also, our toolchain links that library in dynamically, so many of your binaries should have it linked in (see it in `ldd` output)

the file you refer to:
/home/duraid/garnome/lib/libgtk-x11-2.0.so.0
is that something you built yourself ?  or is that a binary library you downloaded that was originally built for x86 ?
Comment 2 SpanKY gentoo-dev 2004-09-07 15:21:26 UTC
try rebuilding the packages that have suddenly broken