Re: [Cooker] Bitten by 'undefined symbol: __dso_handle'
On 14 Nov 2002 at 16:19, Mark Scott wrote: On some libraries I could get away with just removing an unnecessary inclusion of iostream from the source, removing the need for the library to want __dso_handle. This might be why the simple libraries load. Hey. That was a one hell of an advise. I kicked iostream out (thankfully I could) and it worked like charm.. I hope libstdc++ gets straight some day. Will keep checking this periodically. Right now I can afford with no libstdc++ for the time being but may need it in future.. Thanks again.. Bye Shridhar -- Unfair animal names:-- tsetse fly -- bullhead-- booby -- duck-billed platypus-- sapsucker-- Clarence -- Gary Larson
Re: [Cooker] Bitten by 'undefined symbol: __dso_handle'
Shridhar Daithankar wrote: On 14 Nov 2002 at 16:19, Mark Scott wrote: On some libraries I could get away with just removing an unnecessary inclusion of from the source, removing the need for the library to want __dso_handle. This might be why the simple libraries load. Hey. That was a one hell of an advise. I kicked iostream out (thankfully I could) and it worked like charm.. I hope libstdc++ gets straight some day. Will keep checking this periodically. Right now I can afford with no libstdc++ for the time being but may need it in future.. Let me know if you (or anyone else) find out anything more about this - I don't know why it works (I'm guessing that inclusion of iostream instantiates a couple of classes and so requires __dso_handle). As I said, removing -nostdlib from the link options to g++ was an alternative solution, and did not require removing iostream. __dso_handle was defined as an non-exportable symbol in the library when I did that (instead of an attempted imported symbol). BTW, I'm not convinced this is a bug in libstdc++ or Mandrake's packaging of it, but the same code and Makefiles worked without problem for both gcc-2.96 and gcc-3.0.4 in Mandrake 8.2 -- Mark Scott
[Cooker] Bitten by 'undefined symbol: __dso_handle'
Hi all, I am getting failure on dlopen with dlerror message as 'undefined symbol: __dso_handle'. Following is my system configuration on top of MDK 9.0 These are upgraded packages from cooker today. Besides I have binutils 2.13.1 installed from sources which appear first in path(/usr/local/bin) [shridhardaithan shridhar]$ rpm -qa |grep -i glibc glibc-devel-2.2.5-19mdk glibc-2.2.5-19mdk [shridhardaithan shridhar]$ rpm -qa |grep -i gcc gcc-cpp-3.2-3mdk gcc-3.2-3mdk libgcc1-3.2-3mdk gcc-c++-3.2-3mdk [shridhardaithan shridhar]$ rpm -qa |grep -i binutils binutils-2.12.90.0.15-4mdk libbinutils2-2.12.90.0.15-4mdk [shridhardaithan shridhar]$ I have found that this is something to do with .hidden directive and linker/assembler. Only thing I have not done is compiling gcc by hand. Has anybody else experienced this problem? Any solution? Code used to work fine on MDK 8.2. Besides I do not get this failure for all libraries. Some simple libraries gets loaded but C++ libraries have some problems. Though that's may not be the exact pattern for errors. Just an observation.. TIA.. Shridhar
Re: [Cooker] Bitten by 'undefined symbol: __dso_handle'
Shridhar Daithankar [EMAIL PROTECTED] writes: Hi all, I am getting failure on dlopen with dlerror message as 'undefined symbol: __dso_handle'. Following is my system configuration on top of MDK 9.0 These are upgraded packages from cooker today. Besides I have binutils 2.13.1 installed from sources which appear first in path(/usr/local/bin) [shridhar@daithan shridhar]$ rpm -qa |grep -i glibc glibc-devel-2.2.5-19mdk glibc-2.2.5-19mdk [shridhar@daithan shridhar]$ rpm -qa |grep -i gcc gcc-cpp-3.2-3mdk gcc-3.2-3mdk libgcc1-3.2-3mdk gcc-c++-3.2-3mdk [shridhar@daithan shridhar]$ rpm -qa |grep -i binutils binutils-2.12.90.0.15-4mdk libbinutils2-2.12.90.0.15-4mdk [shridhar@daithan shridhar]$ I have found that this is something to do with .hidden directive and linker/assembler. Only thing I have not done is compiling gcc by hand. Has anybody else experienced this problem? Any solution? Code used to work fine on MDK 8.2. it used to work fine on mdk9.0 too. it used to work fine on cooker too. the odds're high your problem are related to : == Besides I have binutils 2.13.1 installed from sources == and your gcc rebuild
Re: [Cooker] Bitten by 'undefined symbol: __dso_handle'
Shridhar Daithankar wrote:
I am getting failure on dlopen with dlerror message as 'undefined symbol:
__dso_handle'. Following is my system configuration on top of MDK 9.0 These
are upgraded packages from cooker today. Besides I have binutils 2.13.1
installed from sources which appear first in path(/usr/local/bin)
[shridhardaithan shridhar]$ rpm -qa |grep -i glibc
glibc-devel-2.2.5-19mdk
glibc-2.2.5-19mdk
[shridhardaithan shridhar]$ rpm -qa |grep -i gcc
gcc-cpp-3.2-3mdk
gcc-3.2-3mdk
libgcc1-3.2-3mdk
gcc-c++-3.2-3mdk
[shridhardaithan shridhar]$ rpm -qa |grep -i binutils
binutils-2.12.90.0.15-4mdk
libbinutils2-2.12.90.0.15-4mdk
[shridhardaithan shridhar]$
I have found that this is something to do with .hidden directive and
linker/assembler. Only thing I have not done is compiling gcc by hand.
Has anybody else experienced this problem? Any solution? Code used to work
fine on MDK 8.2. Besides I do not get this failure for all libraries. Some
simple libraries gets loaded but C++ libraries have some problems. Though
that's may not be the exact pattern for errors. Just an observation..
Yes! I got the same problems yesterday (both on 9.0 and latest Cooker).
I have not recompiled any binutils/gcc/glibc.
The problem is that crtbegin{,S,T}.o, which define __dso_handle, are not
being included in the library.
I found that removing -nostdlib from my library link options solved the
problem (not fully tested them so there may be other gremlims lurking
from removal of -nostdlib).
On some libraries I could get away with just removing an unnecessary
inclusion of iostream from the source, removing the need for the
library to want __dso_handle. This might be why the simple libraries load.
--
Mark Scott
Re: [Cooker] Bitten by 'undefined symbol: __dso_handle'
On 14 Nov 2002 at 17:10, Thierry Vignaud wrote: the odds're high your problem are related to : == Besides I have binutils 2.13.1 installed from sources == and your gcc rebuild Well.. It didn't worked either with upgraded binutils and gcc. So I installed binutils from sources. And I have yet to rebuild gcc so that's not there.. Looks like building gcc by hand would be a good idea.. Bye Shridhar -- All new:Parts not interchangeable with previous model.
Re: [Cooker] Bitten by 'undefined symbol: __dso_handle'
On 14 Nov 2002 at 16:19, Mark Scott wrote: I found that removing -nostdlib from my library link options solved the problem (not fully tested them so there may be other gremlims lurking from removal of -nostdlib). I don't remember having that option for linker. So in my case this is not an option. On some libraries I could get away with just removing an unnecessary inclusion of iostream from the source, removing the need for the library to want __dso_handle. This might be why the simple libraries load. Hmm.. If iostream is causing problem, then I can have a relook at code and remove it if not required. But that is workaround at the best and not a solution. I can not ask people not to use iostream in their library just because my server application won't tolerate that.. Besides I tried linking /usr/lib/libstdc++.so.5 to /usr/lib/libstdc++.so. No luck.. Do you think rebuilidng libstdc++ would help? What option do I need to tweak.. Bye Shridhar -- Wit, n.:The salt with which the American Humorist spoils his cookery... by leaving it out. -- Ambrose Bierce, The Devil's Dictionary
