[Sqlrelay-discussion] is SQL Relay "relocatable"?
Brought to you by:
mused
|
From: John K. <kl...@gm...> - 2008-03-04 02:55:26
|
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). |