| View previous topic :: View next topic |
| Author |
Message |
ph317
n00b
Joined: 02 Jun 2002
Posts: 43
|
 Posted: Sun Jun 02, 2002 4:50 pm Post subject: Possible *real* __divdi3 fix |
 |
|
Apparently the mysterious __divdi3 unresolved symbol (which was sorta-fixed in an ugly way by putting libgcc_s.so in /etc/ld.so.preload for me, and perhaps others) is due to a change in how gcc-3.1 does libgcc. There's a patch for glibc to make up for the deficiency - my gut feeling is that if you apply this patch against glibc-2.2.5-r2 the __divdi3 problem will go away the "right" way. Haven't confirmed this theory yet, as my patched glibc is still emerge-ing, and will be for a while.
Here's the URL for the email with a patch and explanation (from libc-hacker mailing list):
http://sources.redhat.com/ml/libc-hacker/2002-02/msg00152.html |
|
| Back to top |
|
 |
ph317
n00b
Joined: 02 Jun 2002
Posts: 43
|
| Posted: Sun Jun 02, 2002 5:16 pm Post subject: |
|
|
| yup, so far so good - I added the divdi3 patch into my glibc-2.2.5-r2 ebuild, "emerge glibc", rebooted just in case, and now I don't need /etc/ld.so.preload or LD_PRELOAD or anything - nvidia glx, etc, etc all work fine and no unresolved __divdi3 |
|
| Back to top |
|
|
may1937
n00b
Joined: 29 May 2002
Posts: 15
|
| Posted: Sun Jun 02, 2002 9:54 pm Post subject: |
|
|
| you're my new hero =] |
|
| Back to top |
|
|
lx
Veteran
Joined: 28 May 2002
Posts: 1012
Location: Netherlands
|
| Posted: Sun Jun 02, 2002 10:55 pm Post subject: |
|
|
What problem does this fix, only seen it in the forum with nvidia and opengl, and mine system works fine, although the nvidia driver depends on __dvidi3. I'm using the march=athlon-tbird, which activates mmx and 3dnow, somehow I think using this the __divdi3 call is replaced in the optimisation process by using the direct access calls to a arithmic function provided by one of these mechanisms. Read somewhere gcc3 was able to optimise the call away. How would you else explain why this doesn't occur with my system.
This is just a wild guess. Cya lX.
_________________
"Remember there's a big difference between kneeling down and bending over.", Frank Zappa |
|
| Back to top |
|
|
may1937
n00b
Joined: 29 May 2002
Posts: 15
|
| Posted: Sun Jun 02, 2002 11:22 pm Post subject: |
|
|
| I think it only occurs if you have gcc3.1 and binutils 2.12.90.0.7. Read the message on the libc-hacker list.. something about libgcc having it .hidden and unexportable. |
|
| Back to top |
|
|
lx
Veteran
Joined: 28 May 2002
Posts: 1012
Location: Netherlands
|
| Posted: Sun Jun 02, 2002 11:35 pm Post subject: |
|
|
| may1937 wrote: | | I think it only occurs if you have gcc3.1 and binutils 2.12.90.0.7. Read the message on the libc-hacker list.. something about libgcc having it .hidden and unexportable. |
I read it and it says nothing about binutils, or maybe I'm just too tired, but any way I will find out when I recompile my system (some weeks from now, thinking of bying another harddisk and activate my promise raid chip to utilise a raid-0).
Cya, lX
_________________
"Remember there's a big difference between kneeling down and bending over.", Frank Zappa |
|
| Back to top |
|
|
ph317
n00b
Joined: 02 Jun 2002
Posts: 43
|
| Posted: Mon Jun 03, 2002 3:04 pm Post subject: |
|
|
Yeah I think it was supposed to be a non-issue - they made the divdi3 call in libgcc_s.so hidden with gcc-3.1, but apparently it's ok because gcc-3.1 doesn't generate calls to this function. The problem is that certain other libraries and binaries that vendors compile (noteable in this case NVidia's GLX) were compiled with a pre-3.1 gcc, and expect to load divdi3 from libgcc_s.so. I'm not sure why preloading libgcc_s unhides the symbol, but it's a hack any way you look at it. The patch from libc-hackers adds divdi3 into libc, so that binaries that need it can find it.
There are two problems with /etc/ld.so.preload hack - 1) Gentoo's emerge system messes with ld.so.preload, which screws the hack up. 2) it doesn't fix layered dependecies. If a program depends directly on the nvidia GL, then putting libgcc_s into preload fixes it, but if your software depends on a library that then depends on GL (making it indirect), the preload fix doesn't solve the problem.
Speaking of (1) above - it really bugs me that emerge messes with the system's /etc/ld.so.preload - what's this libsandbox, and why is my whole system being forced to preload it while I'm running a compile in one terminal window? |
|
| Back to top |
|
|
lx
Veteran
Joined: 28 May 2002
Posts: 1012
Location: Netherlands
|
| Posted: Mon Jun 03, 2002 3:37 pm Post subject: |
|
|
I use the nvidia GLX driver and it works, but well I compiled it using the old binutils, but I will try if I need this patch next time I recompile my whole system.
libsandbox is used to protect the root (/) filesystem during the emerge procedure (compile/install). I think you could turn it off by editing /etc/make.globals and change FEATURES="sandbox". Some months ago this feature was turned off and only recommended for developers.
Cya lX.
_________________
"Remember there's a big difference between kneeling down and bending over.", Frank Zappa |
|
| Back to top |
|
|
ZeroStar
n00b
Joined: 03 Jun 2002
Posts: 9
Location: Tennessee, USA
|
| Posted: Mon Jun 03, 2002 7:00 pm Post subject: |
|
|
How do you go about applying this patch? If someone could explain this or point me in the right direction to learn how to do this it would be very helpful.
I tried doing a search here and on google and I could not find info on how to apply this or any patch.
Thank you in advance... |
|
| Back to top |
|
|
Klavs
Guru
Joined: 22 May 2002
Posts: 536
Location: Denmark
|
| Posted: Mon Jun 03, 2002 7:06 pm Post subject: |
|
|
first do man patch 
a brief intro would be something like this (for a kernel patch for example):
your kernel is untar'ed into /usr/src/linux
cd /usr/src/linux
zcat gzipped-patch-file | patch -p1
-p1 means strip 1 directory from the path ( see the beginning of the patch-file)
it would be -p0 if you were in /usr/src instead (but then you should be sure that linux is also the path mentioned in the patch.
Hope it helps.
_________________
Best regards,
Klavs Klavsen
Denmark
Working with Unix is like wrestling a worthy opponent.
Working with windows is like attacking a small whining child
who is carrying a .38. |
|
| Back to top |
|
|
ph317
n00b
Joined: 02 Jun 2002
Posts: 43
|
| Posted: Mon Jun 03, 2002 7:53 pm Post subject: |
|
|
On applying the patch (I'm assuming you understand basically how patch and diff work, and you're interested in making it work with Gentoo's ebuild - kinda the boat I was in when I found this glibc patch) -
(note I'm doing this from memory at work, some directory names might be "off" a bit or something)
Get the patch from that email archive link, paste into a plaintext file "glibc-divdi3.diff". Run over the file with perl, sed, vi, or by hand or whatever, and translate any lingering htmlisms to normal characters ("&<> become "&<> respectively).
Copy the patch to /usr/portage/sys-libs/glibc/files
Edit /usr/portage/sys-libs/glibc/glibc-2.2.5-r2.ebuild
Find the section where it applies patches, add in patch -p1 < glibc-divdi3.diff in there, much like the other patches (main difference is you use -p1 instead of their -p0)
Then get back to your shell prompt and "emerge glibc", it will unpack the glibc tarball and build it with your new patch and install it. |
|
| Back to top |
|
|
ZeroStar
n00b
Joined: 03 Jun 2002
Posts: 9
Location: Tennessee, USA
|
| Posted: Mon Jun 03, 2002 10:15 pm Post subject: |
|
|
Thank you very much for your help! I had never thought about editing the ebuild. I have never done that before. Your instructions were very helpful. I was able to apply the patch and re-emerge glibc successfully.
--Wow, you gotta love the linux community. Ask a question and you get help within the hour! Thanks again! |
|
| Back to top |
|
|
lasse
n00b
Joined: 30 May 2002
Posts: 11
Location: Wellington, NZ
|
| Posted: Tue Jun 04, 2002 6:03 am Post subject: |
|
|
| ph317 wrote: | Yeah I think it was supposed to be a non-issue - they made the divdi3 call in libgcc_s.so hidden with gcc-3.1, but apparently it's ok because gcc-3.1 doesn't generate calls to this function. The problem is that certain other libraries and binaries that vendors compile (noteable in this case NVidia's GLX) were compiled with a pre-3.1 gcc, and expect to load divdi3 from libgcc_s.so. I'm not sure why preloading libgcc_s unhides the symbol, but it's a hack any way you look at it. The patch from libc-hackers adds divdi3 into libc, so that binaries that need it can find it.
|
I'm not a linker expert but I think this is slightly incorrect. The basic problem is that nvidia did not explicitly add -lgcc_s to the link line when building the shared library. This means that their shared library contains an implicit dependecy on libgcc_s since the compiler generates code that calls functions in that library. Bottom line is that ldd libGL.so does not report libgcc_s.so.1 as a dependency despite the code in the library being dependent on one or more functions from libgcc_s. Instead, they implicitly (and most likely unknowingly) relied on the linker re-exporting that particular symbol at linktime of the client application.
This implicit inclusion of libgcc_s in the target object happened because the earlier version of binutils ignored the HIDDEN attribute which if defined for a symbol/entry-point states that it is illegal to re-export it. The newer binutils OTOH does honour the HIDDEN attribute so the symbol doesn't get re-exported and the target binary won't contain the reference to libgcc_s. Which leaves us with a link error at runtime since no shared library referenced by the binary contains the symbol __divdi3.
In essence, assume we are building binary A. It uses functions from shared lib B and therefore link against B. The compiler that built B generated calls to mystical functions from shared lib C. (I call them mystical cause the author of B doesn't know this is happening, the functions are house-keeping functions of the compiler. The compiler vendor regards the functions as private and wants to keep them hidden so they don't have to support them forever). With the 2.11.x binutils ldd A would render references to B as well as C since the linker would realise that in order to build a sane binary functions in C have to be re-exported. With the latest binutils A only contains a reference to B since the linker is prevented from re-exporting the symbol in question. The dependency on C has to be fulfilled by other means.
One way to accomplish this is telling the linker to preload libgcc_s. All the symbols defined in libgcc_s implicitly becomes available to _every_ binary on the system at runtime, regardless of whether it was included in the link options at linktime or not. This is a dangerous practice since someone with malicious intent could set the system up to preload a library containing their own evil implementations of selected functions.
Another way is for nvidia to release a version of B where the C dependency was made explicit on the link line when building B. Unless my theories are complete twaddle I don't think the nvidia openGL shared lib would even build using the latest binutils beacuse of this.
Nvidia apparently were far from the only ones hit by this (openssh, sendmail and probably other) and this is most likely why the glibc developers decided to put the concerned functions into glibc. By doing so they are providing the backwards compatibility that gcc lacks. So, in the future this symbol will be defined in libgcc_s as well as glibc.
All this would be trivial if everything was built using the same compiler/linker/libraries but as we all know that's not an option in this case. |
|
| Back to top |
|
|
lx
Veteran
Joined: 28 May 2002
Posts: 1012
Location: Netherlands
|
| Posted: Tue Jun 04, 2002 10:03 am Post subject: |
|
|
Damn, this cleared things up, very elaborate and convincing story lasse. Think this covers the subject, well why is it HIDDEN in the first place, but never mind, when using binutils 2.12 you need the patch. 
_________________
"Remember there's a big difference between kneeling down and bending over.", Frank Zappa |
|
| Back to top |
|
|
ph317
n00b
Joined: 02 Jun 2002
Posts: 43
|
| Posted: Tue Jun 04, 2002 5:11 pm Post subject: |
|
|
Yeah, that explanation sounds a good bit better than what I thought the problem was. I've hit a similar problem in another library now too...
emerge smpeg
emerge xmms-smpeg
when xmms-smpeg runs ./configure, the configure fails when trying to detect the prescence of libsmpeg.so by compiling against it.
So I made a test C program that used a libsmpeg function, and ran "gcc -o test test.c -lsmpeg", I get four unresolved symbols (new(), delete(), and another mangled up form of new() and delete()). Running "gcc -o test test.c -lsmpeg -lstdc++" of course resolved the symbols. I'm assuming smpeg and xmms-smpeg compile correctly in a normal gcc2.95 system, so I'm guessing this stdc++ linking thing might be similar in nature to the divdi3 problem? Any insight? |
|
| Back to top |
|
|
lx
Veteran
Joined: 28 May 2002
Posts: 1012
Location: Netherlands
|
| Posted: Wed Jun 05, 2002 12:25 am Post subject: |
|
|
Tip (a bit offtopic)
check this out:
https://forums.gentoo.org/viewtopic.php?t=101
build glibc with your desired locals. This can speed up the build process and safe you some harddisk space.
Cya lX.
_________________
"Remember there's a big difference between kneeling down and bending over.", Frank Zappa |
|
| Back to top |
|
|
Utoxin
Guru
Joined: 19 Apr 2002
Posts: 413
Location: American Fork, UT
|
| Posted: Wed Jun 05, 2002 12:42 am Post subject: |
|
|
Thanks for pointing that article out. I'll definately give it a try. |
|
| Back to top |
|
|
lx
Veteran
Joined: 28 May 2002
Posts: 1012
Location: Netherlands
|
| Posted: Wed Jun 05, 2002 9:28 pm Post subject: |
|
|
Newsflash: glibc-2.2.5-r4 contains glibc-divdi3.diff patch
| Quote: | 5 June 2002; Bart Verwilst <verwilst@gentoo.org> glibc-2.2.5-r4.ebuild :
Added gcc3.1/binutils 2.12 patch, wich solves the nvidia-glx package,
amongst others... (__divdi3 stuff) |
'm r3 has a fix for sandbox, this is not in r2 and r4?
| Quote: | 03 Apr 2002; Geert Bevin <gbevin@gentoo.org> glibc-2.2.5-r3.ebuild,
files/digest-glibc-2.2.5-r3, files/glibc-2.2.5-sandbox.diff :
Added patch that fixes an ld.so.preload bug which made calls after freopen()
segfault. This now works correctly. This closes bug #501 |
So if you want to recompile glibc or install gentoo with gcc 3.1 you can test this new package. Seems this post is obsolete............., another one for the good guys,...........
Cya lX
_________________
"Remember there's a big difference between kneeling down and bending over.", Frank Zappa |
|
| Back to top |
|
|
rac
Bodhisattva
Joined: 30 May 2002
Posts: 6553
Location: Japanifornia
|
| Posted: Sun Aug 18, 2002 11:07 pm Post subject: |
|
|
Tough call. GCC3 to Other Things Gentoo, as it looks more of a straight GCC issue rather than anything Portage-specific.
_________________
For every higher wall, there is a taller ladder |
|
| Back to top |
|
|
Ansorg
Apprentice
Joined: 13 Jul 2002
Posts: 193
|
| Posted: Wed Aug 21, 2002 9:59 pm Post subject: |
|
|
| lx wrote: | Newsflash: glibc-2.2.5-r4 contains glibc-divdi3.diff patch
| Quote: | 5 June 2002; Bart Verwilst <verwilst@gentoo.org> glibc-2.2.5-r4.ebuild :
Added gcc3.1/binutils 2.12 patch, wich solves the nvidia-glx package,
amongst others... (__divdi3 stuff) |
'm r3 has a fix for sandbox, this is not in r2 and r4?
| Quote: | 03 Apr 2002; Geert Bevin <gbevin@gentoo.org> glibc-2.2.5-r3.ebuild,
files/digest-glibc-2.2.5-r3, files/glibc-2.2.5-sandbox.diff :
Added patch that fixes an ld.so.preload bug which made calls after freopen()
segfault. This now works correctly. This closes bug #501 |
So if you want to recompile glibc or install gentoo with gcc 3.1 you can test this new package. Seems this post is obsolete............., another one for the good guys,...........
Cya lX |
hi,
I just build a system from gentoo-1.4-athlon-stage3 and X reports
this __divdi3 undefined symbol.
how comes that this fix is not in glibc-2.2.5-r7 ?
_________________
thanks
Jens |
|
| Back to top |
|
|
|
Other Things Gentoo
