From: Victor Lu <v....@ga...> - 2005-11-21 20:18:09
|
I have tried to install sybase-0.37.tar on my sun server (sunos 5.6, sybase version 11.0.2). I installed as follows: python setup.py install and the installation ran to completion without any errors. After launching python I then get the following error: Python 2.4 (#1, Nov 18 2005, 14:53:00) [GCC 3.3.2] on sunos5 Type "help", "copyright", "credits" or "license" for more information. >>> import Sybase Traceback (most recent call last): File "<stdin>", line 1, in ? File "/usr/local/lib/python2.4/site-packages/Sybase.py", line 20, in ? from sybasect import * ImportError: ld.so.1: python: fatal: relocation error: file /home/ disk1/server/lib/libtcl.so: symbol svr4_tli: referenced symbol not found >>> I know there was a similar posting by Steve Bremer http://www.object- craft.com.au/pipermail/python-sybase/2003-June/000177.html but there was no reply to his question. I'd be grateful for any assistance. Victor |
From: Gregory B. <gn...@it...> - 2005-11-21 20:20:55
|
Victor Lu wrote: > ImportError: ld.so.1: python: fatal: relocation error: file /home/ > disk1/server/lib/libtcl.so: symbol svr4_tli: referenced symbol not found Check that your LD_LIBRARY_PATH is set right. (i.e. $SYBASE/SYBASE.sh is sourced.) |
From: Marcos P. <ma...@bu...> - 2005-11-23 11:07:55
|
It seems that we need more explicit error messages ;-) El lun, 21-11-2005 a las 12:20 +1100, Gregory Bond escribió: > Victor Lu wrote: > > > ImportError: ld.so.1: python: fatal: relocation error: file /home/ > > disk1/server/lib/libtcl.so: symbol svr4_tli: referenced symbol not found > > Check that your LD_LIBRARY_PATH is set right. (i.e. $SYBASE/SYBASE.sh > is sourced.) > _______________________________________________ > Python-sybase mailing list > Pyt...@ww... > https://www.object-craft.com.au/cgi-bin/mailman/listinfo/python-sybase -- Marcos Sánchez Provencio <ma...@bu...> |
From: Don K. <da...@pr...> - 2005-11-23 11:20:50
|
On Nov 22, 2005, at 9:07 AM, Marcos S=E1nchez Provencio wrote: > It seems that we need more explicit error messages ;-) > > El lun, 21-11-2005 a las 12:20 +1100, Gregory Bond escribi=F3: >> Victor Lu wrote: >> >>> ImportError: ld.so.1: python: fatal: relocation error: file /home/ >>> disk1/server/lib/libtcl.so: symbol svr4_tli: referenced symbol =20 >>> not found He could be getting the libtcl.so for the TCL/Tk programming language before the Sybase library of the same name. hail{dak}1056: ls -l $SYBASE/lib/libtcl.* -rwxrwxr-x 1 sybase 420372 Nov 20 1997 /usr/local/sybase/lib/=20 libtcl.so hail{dak}1057: ls -l /usr/local/pkg/tcl-8.3.1/lib/libtcl.so lrwxrwxrwx 1 root 12 Aug 10 2000 /usr/local/pkg/=20 tcl-8.3.1/lib/libtcl.so -> libtcl8.3.so I guess the LD_LIBRARY_PATH is still suspect. >> >> Check that your LD_LIBRARY_PATH is set right. (i.e. $SYBASE/=20 >> SYBASE.sh >> is sourced.) >> _______________________________________________ >> Python-sybase mailing list >> Pyt...@ww... >> https://www.object-craft.com.au/cgi-bin/mailman/listinfo/python-=20 >> sybase > --=20 > Marcos S=E1nchez Provencio <ma...@bu...> > > _______________________________________________ > Python-sybase mailing list > Pyt...@ww... > https://www.object-craft.com.au/cgi-bin/mailman/listinfo/python-sybase -- Don Kiphart Software Developer Prediction Company Santa Fe, NM |
From: <sk...@po...> - 2005-11-23 13:52:55
|
>> > ImportError: ld.so.1: python: fatal: relocation error: file /home/ >> > disk1/server/lib/libtcl.so: symbol svr4_tli: referenced symbol not >> > found >> >> Check that your LD_LIBRARY_PATH is set right. >> (i.e. $SYBASE/SYBASE.sh is sourced.) Marcos> It seems that we need more explicit error messages ;-) That's only useful up to a point. There are plenty of error messages in Python that could be more user-friendly. This probably isn't one of them though. The code in Python that raises the ImportError exception doesn't really know the details of why the import failed, only that it failed. dlopen() failures can happen for lots of reasons. Here's the relevant bit from the dlopen() man page on Solaris 10 about return values. The dlopen() function returns NULL if pathname cannot be found, cannot be opened for reading, or is not a shared object or a relocatable object. dlopen() also returns NULL if an error occurs during the process of loading pathname or relocating its symbolic references. See NOTES. Additional diagnostic information is available through dlerror(). Python (perhaps helpfully, perhaps not) regurgitates the message from dlerror(). It has no control over the content of that message, and it probably has no business trying to interpret it. -- Skip Montanaro Katrina Benefit Concerts: http://www.musi-cal.com/katrina sk...@po... |
From: Marcos P. <ma...@bu...> - 2005-11-23 17:55:26
|
You are very right, but how many times has someone answered >> Check that your LD_LIBRARY_PATH is set right. >> (i.e. $SYBASE/SYBASE.sh is sourced.) ? PS I'll use the same postage stamp to say thanks to the author/s of this module. :-) El mar, 22-11-2005 a las 12:52 -0600, sk...@po... escribió: > >> > ImportError: ld.so.1: python: fatal: relocation error: file /home/ > >> > disk1/server/lib/libtcl.so: symbol svr4_tli: referenced symbol not > >> > found > >> > >> Check that your LD_LIBRARY_PATH is set right. > >> (i.e. $SYBASE/SYBASE.sh is sourced.) > > Marcos> It seems that we need more explicit error messages ;-) > > That's only useful up to a point. There are plenty of error messages in > Python that could be more user-friendly. This probably isn't one of them > though. The code in Python that raises the ImportError exception doesn't > really know the details of why the import failed, only that it failed. > dlopen() failures can happen for lots of reasons. Here's the relevant bit > from the dlopen() man page on Solaris 10 about return values. > > The dlopen() function returns NULL if pathname cannot be > found, cannot be opened for reading, or is not a shared > object or a relocatable object. dlopen() also returns NULL > if an error occurs during the process of loading pathname or > relocating its symbolic references. See NOTES. Additional > diagnostic information is available through dlerror(). > > Python (perhaps helpfully, perhaps not) regurgitates the message from > dlerror(). It has no control over the content of that message, and it > probably has no business trying to interpret it. > |