Installing DBD::Sybase when there is no compiler

[Yash]

Hi,

At our customer's site, there is Perl 5.6.1 installed on HP-Ux 11.
This does not have the DBD::Sybase perl module. For the new version of
our application, we are required to interact with an SQL Server 2000
database running on a remote Windows machine.
We managed to build and install the module on our development
machines. For this we had to first install FreeTDS as the driver.
While doing a make of the Sybase module , we had to give the location
of the FreeTDS in an env. variable. The module was built and
installed. However, the Sybase.pm file uses Sybase.sl which tries to
load /home/myhome/freetds/lib/libtds.sl.3.
/home/myhome/freetds is where we installed the FreeTDS on the
development machine. However on the customer's machine, FreeTDS may be
installed in some other directory.
On the customer's site, there is not compiler present. So we will have
to ship the pre-built perl module.
Can someone suggest how to build the perl module on the dev. machine
so that the packaged module does not depend on the location of the
libraries it uses.

Thanks

 

[MrReallyVeryNice]

While I'm unable to answer your real question about building the perl module
on your dev. machine
so that the packaged module does not depend on the location of the libraries
it uses, I may help a little. Let's say that in a previous life I was very
much involved with Configuration Management teams. One of the big tasks of
my Configuration Management teams was to deliver software packages on
computers for our internal/external customers. Just trying to hint that I
have a bit of practice in this area but take everything I say with a grain
(or a spoon) of salt. Consider that what was acceptable in our corporation
would/might not be acceptable in another corporation. You have to know your
customer and work with them. But enough about the high level stuff, let's
talk about a process driven solution.

Contact your customer sys admins and negotiate with them the location of the
libtds.sl.3 and other potential supporting software. With that information,
compile your application with libtds.sl.3 in the appropriate location and
write a little "Installation Note". At install time, the sys admin will
simply have to follow your notes (I would be surprised if they let you
install the application by yourself). If something goes wrong, they have the
documentation as a support and you have the documentation to prove that you
followed some kind of agreed process. CYA This approach is not really
flexible to move libraries and applications around. It also requires up
front communication (not a bad thing in any case) with your customer. Based
on your confidence level on the sys admins skill set, you might decide to
package and install libtds.sl.3 in a sub-directory of where your application
would be installed. While most sys admin are really knowledgeable and
skilled, you might deal with a small corporation where "cow-boys" are
running the show. It means that they might have little
control/knowledge/information about where various pieces gets installed over
time. Corporations that keep good logs of system changes are always too
rare. :-( In the case of a disorganized customer , it is possible that a
sys admin would upgrade/downgrade libtds.sl.3 in the process of supporting
another application. In which case, you are taking the risk of getting your
application broken in the process. Packaging libtds.sl.3 within your
application - if acceptable for your customer - would alleviate future
headaches but might led to duplication of library. It is a tradeoff that you
will have to assess.

I hope that someone out there will give 'the real' answer that you are
looking for. I would love to learn how it can be done.

You most likely already figured out a solution but let me know if this
posting helps.
Mr ReallyVeryNice.


http://mail.augustmail.com/~tadmc/clpmisc/clpmisc_guidelines.html
http://mail.augustmail.com/~tadmc/clpmisc/clpmisc_guidelines.html
http://mail.augustmail.com/~tadmc/clpmisc/clpmisc_guidelines.html
http://mail.augustmail.com/~tadmc/clpmisc/clpmisc_guidelines.html
http://mail.augustmail.com/~tadmc/clpmisc/clpmisc_guidelines.html
Just trying to catch the attention of people about this wonderful document.
This reference does not specifically pertain to my reply or to the OP.