From: Gregory B. <gn...@it...> - 2004-03-10 17:27:37
|
jj...@po... said: > First, is the sybase module known to work with Sybase 12.5? Yes. At least, it does for everything I've tried. Gotta get the LD_LIBRARY_PATH stuff right, esp. if you want the same .so to work for 11.5, 12.0 and 12.5 (which it seems to no problems). |
From: Jeff Y. <jyo...@of...> - 2004-03-11 19:27:49
|
The LD_LIBRARY_PATH needs to be set the the location of the shared libs at runtime. Mine is set to: ${SYBASE_HOME}/OCS/lib -jeff |
From: Andrew M. <an...@ob...> - 2004-03-10 17:55:11
|
>Yes. At least, it does for everything I've tried. Gotta get the >LD_LIBRARY_PATH stuff right, esp. if you want the same .so to work for 11.5, >12.0 and 12.5 (which it seems to no problems). BTW, Solaris lets you specify a run-time library search path at link time with the -R linker option (it works like the -L option, which only has an effect at link-time under Solaris). John - did the "symbol not found" error occur on the same machine as you built the module? My immediate thought would be a different library is being found at run-time compared to what setup.py sees (but this is just a guess). -- Andrew McNamara, Senior Developer, Object Craft http://www.object-craft.com.au/ |
From: John J L. <jj...@po...> - 2004-03-11 18:39:30
|
On Wed, 10 Mar 2004, Andrew McNamara wrote: [...] > John - did the "symbol not found" error occur on the same machine as you > built the module? Yes. > My immediate thought would be a different library is > being found at run-time compared to what setup.py sees (but this is just a > guess). We should just need SYBASE set properly in the environment, right? (and SYBASE_OCS, but I guess that's not the problem) I thought I'd done that right, but I can't swear to it. [...] > Andrew McNamara, Senior Developer, Object Craft Oh, hi again Andrew :-) I thought I recognized your name from somewhere... John |
From: Dave C. <dj...@ob...> - 2004-03-11 19:01:32
|
On Thu, 2004-03-11 at 10:39, John J Lee wrote: > On Wed, 10 Mar 2004, Andrew McNamara wrote: > [...] > > John - did the "symbol not found" error occur on the same machine as you > > built the module? > > Yes. > > > > My immediate thought would be a different library is > > being found at run-time compared to what setup.py sees (but this is just a > > guess). > > We should just need SYBASE set properly in the environment, right? (and > SYBASE_OCS, but I guess that's not the problem) I thought I'd done that > right, but I can't swear to it. I am not sure that distutils knows how to use the -R when building on Solaris. Hmm... There seems to be some code in there (distutils.unixcmpiler) to do it - I just am not sure it happens by default. - Dave -- http://www.object-craft.com.au |
From: Andrew M. <an...@ob...> - 2004-03-11 21:20:19
|
>> John - did the "symbol not found" error occur on the same machine as you >> built the module? > >Yes. I ask, because the error you reported doesn't say the library wasn't found, but rather that a symbol within the library wasn't found - which suggests to me that it found a library, but it was the wrong one. Is there any chance there's the ditritus from an old Sybase install on the machine? >> My immediate thought would be a different library is >> being found at run-time compared to what setup.py sees (but this is just a >> guess). > >We should just need SYBASE set properly in the environment, right? (and >SYBASE_OCS, but I guess that's not the problem) I thought I'd done that >right, but I can't swear to it. Uh - that would imply something somewhere was smart enough to use the variable to set the run-time library search path on the resulting shared library. Without something that fills the role of apache's apxs, this probably won't happen. As Jeff Younker suggests, try setting LD_LIBRARY_PATH to include the sybase lib directory and see if that helps. If it does, then you can try playing games with distutil to get the right -R option passed through to the linker, or just live with LD_LIBRARY_PATH (most people do the later... 8-) >> Andrew McNamara, Senior Developer, Object Craft > >Oh, hi again Andrew :-) I thought I recognized your name from >somewhere... Freaky. Small world. 8-) -- Andrew McNamara, Senior Developer, Object Craft http://www.object-craft.com.au/ |
From: John J L. <jj...@po...> - 2004-03-12 04:34:09
|
On Thu, 11 Mar 2004, Andrew McNamara wrote: [...] > I ask, because the error you reported doesn't say the library wasn't > found, but rather that a symbol within the library wasn't found - which > suggests to me that it found a library, but it was the wrong one. Is there Sure. I asked here about it because it seemed that setup.py setups up a preprocessor macro that I suspected might have been intended to ifdef out the offending use of blk_alloc on this particular setup. [...] > >> My immediate thought would be a different library is > >> being found at run-time compared to what setup.py sees (but this is just a > >> guess). > > > >We should just need SYBASE set properly in the environment, right? (and > >SYBASE_OCS, but I guess that's not the problem) I thought I'd done that > >right, but I can't swear to it. > > Uh - that would imply something somewhere was smart enough to use the > variable to set the run-time library search path on the resulting shared > library. Without something that fills the role of apache's apxs, this > probably won't happen. [...] That something was me ;-) I set LD_LIBRARY_PATH before importing the module. I just meant that SYBASE & SYBASE_OCS controls where setup.py finds things (and LD_LIBRARY_PATH controls where ld finds them). I'm pretty sure these were the values of the relevant environment variables: SYBASE /export/sybase/sybase_12.5 SYBASE_OCS OCS-12_5 LD_LIBRARY_PATH "/usr/local/lib:/export/sybase/sybase_12.5/OCS-12_5/lib" Unless I messed that up somehow, it should work, right? John |
From: Andrew M. <an...@ob...> - 2004-03-12 06:07:56
|
>> I ask, because the error you reported doesn't say the library wasn't >> found, but rather that a symbol within the library wasn't found - which >> suggests to me that it found a library, but it was the wrong one. Is there > >Sure. I asked here about it because it seemed that setup.py setups up a >preprocessor macro that I suspected might have been intended to ifdef out >the offending use of blk_alloc on this particular setup. I should mention that I know next to nothing about the python-sybase module, although I've butted heads with Solaris for a few years now. I was hoping some general Solaris observations would help. 8-) -- Andrew McNamara, Senior Developer, Object Craft http://www.object-craft.com.au/ |