[Sqlrelay-discussion] is SQL Relay "relocatable"?

[John K. <kl...@gm...>]

I'm attempting to install SQL Relay into a company-wide, distributed
filesystem...  One of the requirements is:

> Make sure your binary package is relocatable.
> This is more important than it sounds; many binary
> packages have hardcoded paths and expect to be
> installed in a particular place.

Given this "definition" (if you will), is SQL Relay relocatable?  Do I
need to do anything special, to make it so?

I ask, because did some playing around, as follows:

1. I built SQL Relay with a --prefix, and then installed it (call the
location ORIG).

2. I tarred up the installation, and copied it elsewhere (call the
location MOVE).

3. I ran a perl test script against MOVE, and it seemed to work.
However, a truss revealed that it was still looking for the libraries
in ORIG -- even though, after not finding them, it was able to
successfully move on, and find them in MOVE.

In my case, though, the fact that it looked in ORIG at all, is bad.  I
can't afford to have clients hit ORIG, from anywhere and everywhere on
our global intranet.  They need to go to MOVE, period.

Pointers/advice/thoughts?  Is this something I can set up, or manage,
via "configure" options?

The closest thing I see is the rpath options, for which the "disable"
versions are limited to:

  --disable-oracle-rpath        Don't use -rpath when building Oracle connection
  --disable-freetds-rpath       Don't use -rpath when building FreeTDS
connection
  --disable-sybase-rpath      Don't use -rpath when building Sybase connection
  --disable-db2-rpath            Use -rpath when building DB2 connection

This doesn't seem to cover all bases...

After reading "rpath considered harmful"
(http://people.debian.org/~che/personal/rpath-considered-harmful),
rpath seemed the likely culprit.  I'm no longer sure, though.

Thanks.

P.S. We do have a build environment, for building things that are
destined for this company-wide, distributed filesystem.  I can't get
SQL Relay to build there, though, and so was falling back to the
next-best thing (which is to create a binary elsewhere, and then
install *that* instead).