view release on metacpan or  search on metacpan

FAQ  view on Meta::CPAN

      $ENV{SYBASE} = '/opt/sybase';
}

use strict;
use Sybase::CTlib;

etc...

Another potential problem is an LD_LIBRARY_PATH setting error. The
HTTP deamon does not normally set this environment variable when
executing child processes. Again, you may be able to set the
LD_LIBRARY_PATH environment variable via an http server configuration
file. Note that it is not possible to set the LD_LIBRARY_PATH
environment variable in the script itself (the variable needs to be
set before the execution starts), so you may need to write a small
shell wrapper that sets this environment variable and then execs your
script. 

Alternatively, link the Sybase shared libraries to one of the default
directories (such as /usr/lib). 

2.6 Sybperl won't build / run on Dec Unix / Alpha

Sybperl 2.05 had a bug in the Sybase::CTlib module that caused it to
fail on the Dec Alpha platform. There is a patch for Sybperl 2.05 that
corrects this, and Sybperl 2.06 does not have this problem. 

       OpenClient 10.x:
       Make sure you add -lsdna and -ldnet_stub to the EXTRALIBS line
       in sybperl's CONFIG file.  

       David Thiede also says that the 10.0.4 version of OpenClient is
       incorrectly built for the DEC Unix version. The shared
       libraries can be rebuilt with the following command (make sure
       you have made backup copies first!!!) 

               cc -o lib$1.so -shared -expect_unresolved "*" -all lib$1.a

       where $1 is each of the libraries you wish to change (ct, cs, etc.). 

       OpenClient 11.x
       Add -ltli to EXTRA_LIBS. 

As of version 4.0B DEC includes Berkeley DB in its system. This causes
a conflict with Sybase's DBlibrary, as both DBlibrary and Berkeley DB
have a function called dbopen(). 

The solution is to make sure that perl itself does not reference -ldb
when it is being built (the easiest way to check this is with 

        perl -V:libs

If this includes -ldb then you must rebuild perl, making sure that
-ldb is not included.

It has been repported that sybperl requires LD_LIBRARY_PATH to be set
under certain versions of DEC Unix. If you get a failure at the make
test phase you should set LD_LIBRARY_PATH to point to the Sybase
library directory: 

        setenv LD_LIBRARY_PATH "$SYBASE/lib"

or 

        export LD_LIBRARY_PATH="$SYBASE/lib"

depending on the shell you are using. 

Stuart Garner (stuartmg@newscorp.com) says that one of the problems
with DEC Unix 4.0A is that it includes libtcl.so in /usr/shlib, which
causes problems. Here's his solution: 

       It looks like Digital UNIX 4.0a and highter comes with a
       libtcl.so in /usr/shlib, which is the first directory searched
       during runtime. What I finally ended up doing was the following: 

               perl Makefile.PL
               emacs CTlib/Makefile  <<<---- added -exact_version to LDDLFLAGS
               make
               make test
               make install

       Since the Sybase libtcl.so doesn't have a version number and
       the /usr/shlib/libtcl.so's version number is "osf.1", it finds
       the correct library at runtime. The "-exact_version" flag
       doesn't seem to exist in Solaris 2.6, so I'm assuming it's a
       Digital thing. 

2.7 Sybperl fails on IBM AIX with perl 5.004

There is a strange AutoLoader bug in perl 5.004 on AIX. This can be
fixed by editing CTlib/CTlib.pm and DBlib/DBlib.pm and moving the
__END__ tag to the very end of the file, and rebuilding sybperl. 

2.8 Sybperl fails on Linux RedHat 5.x

Linux RedHat 5.x ships with glibc, rather than the libc. This causes
the original Sybase OpenClient port to Linux to fail miserably. 

The best solution is to get the new Sybase release (see
http://linux.sybase.com)


3. Sybperl 1.x vs Sybperl 2.x

3.1 Are sybperl 1.x scripts compatible with 2.x?

Yes. With these exceptions: 

       @var means different things to Perl and to Transact-SQL. If you
       use @var as SQL code (typically: "declare @var int exec my_proc
       @var out") you need to escape the @ (as in \@var). 
       If you were in the habit of making calls to the sybperl 1.x
       subs without parens (ie &dbnextrow; instead of &dbnextrow())
       then there are certain situations where the dbnextrow
       implementation in sybperl 2.x may try to use an invalid
       DBPROCESS pointer. This problem does not exist if your scripts
       always pass explicit DBPROCESS parameters. 
       The $dbNullIsUndef variable defaults to in sybperl 2.x. It was
       FALSE in sybperl 1.x. This causes NULL values to be returned as
       the perl undef value, rather than the string "NULL".