wilko has asked for the wisdom of the Perl Monks concerning the following question:

Hi Monks
this is my first post. I'm not a Perl expert so go easy on me please :)
I've written a Client/Server app which uses the IO::Socket, IO::Select and Sybase::DBlib modules. The clients send data back to the server process which updates a Sybase table. The problem I have is the dependency on Sybase::DBlib. I want to be able to bundle the Sybase::DBlib Perl Module with my Perl script rather than assuming each system I deploy to will have it installed.
So I manually copied:

/usr/lib/perl5/site_perl/5.8.0/i386-linux-thread-multi/Sybase/* and ..auto/*

to a new server which does not have the Sybase DBlib already installed. I created a subdirectory called ./lib beneath where my perlscript is. At the top of my code I do this:

use lib './lib'; # ./lib contains Sybase and auto
use Sybase::DBlib;

When I run my script, i get the following:

"Can't load './lib/auto/Sybase/DBlib/DBlib.so' for module Sybase::DBlib: ./lib/auto/Sybase/DBlib/DBlib.so: cannot open shared object file: No such file or directory at /usr/lib64/perl5/5.8.5/x86_64-linux-thread-multi/DynaLoader.pm line 230. at ./t line 5 Compilation failed in require at ./t line 5. BEGIN failed--compilation aborted at ./t line 5."

DBlib.so definitely exists in that directory. I've also tried copying DBlib.so to /usr/lib which is in the $LD_LIBRARY_PATH. Perhaps i've made some naiive assumptions about Perl Modules here. Any ideas greatly received.

Rgds
/john

Replies are listed 'Best First'.
Re: Hello Word\n
by derby (Abbot) on Nov 20, 2008 at 13:14 UTC

    In addition to almut's and moritz's reply, you need to remember that the DBlib.so has dependencies on Sybase's client libraries (libsybdb I think). So ... even if the two machines were the same architecture, you would need to copy way more than DBlib.so.

    Even if you copy over libsybdb, there may be many other library dependencies (and/or incompatibilities) you need to worry about. Installing via cpan is your best option. Also, why DBlib? Is there a reason for not using DBD::Sybase?

    -derby

    update: As JavaFan says, this is really a deployment issue. If you have that many servers, it's easier to build on one server (or one server of each architecture type) and then use something like rsync or rdist to deploy.

[reply]
      Thanks derby. i have not looked at DBD::Sybase. Is this better in some way than DBlib? I'm pretty new to the perl world so kinda stumbled into using DBlib. I will have a look...rgds
[reply]

        Yes. I believe DBD::Sybase is the better way to go. Sybase::DBLib is based on the older version of the Sybase client library (DBLib) -- older as in DBLib is from the 80's and the newer CTLib is from the 90's. There's always rumblings that Sybase is going to discontinue DBLib (but that never appears to actually occur).

        You can decide for yourself which c-based lib you want to use by checking out the faq. Your choice of which c-based lib you want to use will influence which perl modules you want/need to use.

        That all being said, DBD::Sybase is the more active module (it's been a few years since Sybase::DBLib has been updated). As with all things perl/sybase, if mpeppler chimes in, takes his advice -- he's the maintainer of most (all?) things sybase/perl. (Also, if jfroebe chimes in, take his advice too -- he's very deeply involved with sybase).

        -derby
[reply]
Re: Hello Word\n
by moritz (Cardinal) on Nov 20, 2008 at 12:38 UTC
    Modules that are not pure Perl (ie with C libraries) can't easily installed by copying the perl files, and the library paths are system dependent.

    Why don't you just install the module via CPAN? cpan -i Sybase::DBlib and you're done.

    P.S. please use a more descriptive title for your posting, like "installing Sybase::DBli' or something, you can change it still.

[reply]
[d/l]
      thanks to all for replies so far...
      The problem with installing the module via CPAN is that it would need to be done on many servers which is not practical. I may need a re-think on how to deploy. It's a shame coz the Clients that I deploy to don't even need the Sybase:DBlib! Only the Server needs it (which already has it installed and working). Thing is, I want all my perl in 1 script which takes a parameter on the command line like Send or Recv depending on whether it's the client(sender) or server(recv)
[reply]
        the Clients that I deploy to don't even need the Sybase:DBlib!

        Well, then don't load it in this case... :)   The if module might come in handy for that.  E.g.

        sub SERVER() {1}   # or: use constant SERVER => 1;

use if SERVER, "Sybase:DBlib";

        [download]
[reply]
[d/l]
        Most unixish systems use some kind of package system for installing software (for example Debian uses .deb, RedHat uses .rpm etc.). Usually it's not that much effort to build such a package for your OS from a CPAN distribution, for example for Debian dh-make-perl really helps.

        Probably such an option is also available for your OS (whatever it is).

[reply]
[d/l]
        The problem with installing the module via CPAN is that it would need to be done on many servers which is not practical.
        You need to compile the sources for each platform/perl version combination you have. How to do this best depends on the infrastructure you have. Go ask around, how do you normally deploy (compiled) software?
[reply]
Re: Installing Sybase::DBlib problems
by almut (Canon) on Nov 20, 2008 at 12:46 UTC 
    .../5.8.0/i386-linux-thread-multi/...
.../5.8.5/x86_64-linux-thread-multi/...

    [download]

    You generally can't mix 32-bit code (the DBlib.so you copied) with 64-bit code (the perl binary on the new server) in one process.

[reply]
[d/l]
[select]

Back to Seekers of Perl Wisdom