Turns out I spent a lot of time getting those -rpaths and -
install_name things to work :) Oh well.
Anyway, seems like three cases:
- Mac OS/X -- without -install_name, it burns in the current build
directory -- I think install_name_tool can be used at install time to
reset.
- On Windows, the convention is to find the .dll's first in the
location the binary is located -- the aolserver install dumps
everything in bin/ so this seems ok.
- On all other Unix, I could purge all the -rpath stuff from the
build so folks are required to do the right thing with
LD_LIBRARY_PATH, ld.config, whatever on their system.
I'm ok with these changes if other folks are -- would simplify the
build logic as well.
-Jim
On Aug 24, 2005, at 6:28 AM, Francesco P. Lovergine wrote:
On Wed, Aug 24, 2005 at 01:14:53AM -0400, Dossy Shiobara wrote:
A simple kludge would be to provide a wrapper script to start nsd
that
sets LD_LIBRARY_PATH accordingly, but this seems like a big kludge.
It's absolutely not a kludge: matter of fact, I think Debian Linux
requires that paths not be burned into binaries with -R so that
they can
be relocated with LD_LIBRARY_PATH.
Yes, by policy. Past experience of libc5->libc6 migration showed that
embedded rpaths create more problems than those they solves. Or
think a
sysadm which need to relocate programs more and more time: it would
require a bounce of symlinks around to maintain compatibility...
--
Francesco P. Lovergine
--
AOLserver - http://www.aolserver.com/
To Remove yourself from this list, simply send an email to
<[EMAIL PROTECTED]> with the
body of "SIGNOFF AOLSERVER" in the email message. You can leave the
Subject: field of your email blank.
--
AOLserver - http://www.aolserver.com/
To Remove yourself from this list, simply send an email to <[EMAIL PROTECTED]>
with the
body of "SIGNOFF AOLSERVER" in the email message. You can leave the Subject:
field of your email blank.
