python-sybase-misc

Re: [python-sybase] CS_MEM_ERROR only in CGI execution environment

[Gregory B. <gn...@it...>]

> I can import Sybase from a Solaris shell prompt fine.
> 
> When I try importing Sybase from code run from a CGI script, though, it
> fails at the first cs_ctx_alloc() in Sybase.py, and I get the following in
> the debug file:

That'll be LD_LIBRARY_PATH issues.  When you do a connect, the sybase
libs dynamically link other libraries, giving these wierd errors if it
fails.  There's no way (afaict) of futzing -R flags at compile time
for this, you just gotta have the right LD_LIBRARY_PATH (or symlink
the offenders into /usr/local/lib or whatever.)

Seems to be a problem with 12.0/12.5 more than 11.0 libraries.

RE: [python-sybase] CS_MEM_ERROR only in CGI execution environment

[Charles B. <Cha...@ut...>]

> > I *am* setting LD_LIBRARY_PATH (using a shell script wrapper around
a
> > Python CGI script), but I guess it's non-Sybase libs that are not
being
> > found.
> [...]
>=20
> LD_LIBRARY_PATH is identical in both shell and CGI script environment.
> Same goes for SYBASE and SYBASE_OCS.
>=20
> None of the other environment variables seem even vaguely relevant.  I
> didn't have time in my most recent visit to slavishly copy the whole
> environment, but I'm doubting again that that's my problem...
>=20
> Still, you may well be right that this is a linking problem.
>=20
> Any other ideas??

I don't know what web server you are running or which version, but in a
previous job, when I routinely built the latest Apache 1.3 with some
bells and whistles, I recall there being some issues caused by mm shared
memory lib support being compiled in.  I was using mod_perl and mod_php
at the time, and not mod_python.  May not be relevant, since one problem
I recall led to the server not even starting.

One tip: 'os.environ' is a dictionary of environment variables for the
current script.  You can use this dictionary to initialize your script
to precisely the same environment your interactive shell enjoys, e.g.:

---------------------------------------------------------
import os
#-- Insert new path at front of LD_LIBRARY_PATH env var
os.environ['LD_LIBRARY_PATH'] =3D
  '/usr/local/freetds/lib:%s' % (os.environ['LD_LIBRARY_PATH'])
#-- Initialize SYBASE env var
os.environ['SYBASE'] =3D '/usr/local/freetds'
#-- etc. etc. etc.
---------------------------------------------------------

This might prevent a slip between the shell and the script ;-)

HTH,

Chuck Bearden
Systems Analyst III
School of Health Information Sciences
University of Texas at Houston
713.500.3954 (voice)
713.500.3907 (fax)
Cha...@ut...

RE: [python-sybase] CS_MEM_ERROR only in CGI execution environment

[John J L. <jj...@po...>]

On Wed, 11 Aug 2004, Charles Bearden wrote:
[...]
> I don't know what web server you are running or which version, but in a
> previous job, when I routinely built the latest Apache 1.3 with some
> bells and whistles, I recall there being some issues caused by mm shared
> memory lib support being compiled in.  I was using mod_perl and mod_php
[...]

mm = memory mapped?  AFAIK, the server in question wasn't built for that,
but it's an idea.  Thanks.


> One tip: 'os.environ' is a dictionary of environment variables for the
> current script.  You can use this dictionary to initialize your script
> to precisely the same environment your interactive shell enjoys, e.g.:
[...]

Sure.  I did that first.  The shell script wrapper was simply paranoia
and/or superstition ;-)


John

Re: [python-sybase] CS_MEM_ERROR only in CGI execution environment

[John J L. <jj...@po...>]

On Sat, 31 Jul 2004, Gregory Bond wrote:

> > I can import Sybase from a Solaris shell prompt fine.
> >
> > When I try importing Sybase from code run from a CGI script, though, it
> > fails at the first cs_ctx_alloc() in Sybase.py, and I get the following in
> > the debug file:
>
> That'll be LD_LIBRARY_PATH issues.  When you do a connect, the sybase
> libs dynamically link other libraries, giving these wierd errors if it
> fails.  There's no way (afaict) of futzing -R flags at compile time
> for this, you just gotta have the right LD_LIBRARY_PATH (or symlink
> the offenders into /usr/local/lib or whatever.)
>
> Seems to be a problem with 12.0/12.5 more than 11.0 libraries.

Thank you!

I've been bashing my head against this for some time now.

I *am* setting LD_LIBRARY_PATH (using a shell script wrapper around a
Python CGI script), but I guess it's non-Sybase libs that are not being
found.

With hindsight, it seems blindingly obvious that I should have rote-copied
the shell environment and then experimented to track this down...  I guess
my mental block was assuming that some obscure Solaris security feature
was to blame.


John

Re: [python-sybase] CS_MEM_ERROR only in CGI execution environment

[John J L. <jj...@po...>]

On Sat, 31 Jul 2004, John J Lee wrote:

> On Sat, 31 Jul 2004, Gregory Bond wrote:
>
> > > I can import Sybase from a Solaris shell prompt fine.
> > >
> > > When I try importing Sybase from code run from a CGI script, though, it
> > > fails at the first cs_ctx_alloc() in Sybase.py, and I get the following in
> > > the debug file:
> >
> > That'll be LD_LIBRARY_PATH issues.  When you do a connect, the sybase
> > libs dynamically link other libraries, giving these wierd errors if it
> > fails.  There's no way (afaict) of futzing -R flags at compile time
> > for this, you just gotta have the right LD_LIBRARY_PATH (or symlink
> > the offenders into /usr/local/lib or whatever.)
> >
> > Seems to be a problem with 12.0/12.5 more than 11.0 libraries.
>
> Thank you!

OK, I take it back ;-)


> I've been bashing my head against this for some time now.
>
> I *am* setting LD_LIBRARY_PATH (using a shell script wrapper around a
> Python CGI script), but I guess it's non-Sybase libs that are not being
> found.
[...]

LD_LIBRARY_PATH is identical in both shell and CGI script environment.
Same goes for SYBASE and SYBASE_OCS.

None of the other environment variables seem even vaguely relevant.  I
didn't have time in my most recent visit to slavishly copy the whole
environment, but I'm doubting again that that's my problem...

Still, you may well be right that this is a linking problem.

Any other ideas??


John