FreeTDS Development Group

["Castellano, Nicholas" <Nicholas_Castellano AT acml.com>]

Jim,

I agree with Merijn.  I'm not really sure that Steve disagrees, I think he's
just griping about how much ELF sucks (and I'd have to agree with that).

Having an embedded -rpath does not preclude the use of LD_LIBRARY_PATH.  So
clearly the right thing to do is give an -rpath indicating where the ODBC
library was found at build time.  Those who want or need to use
LD_LIBRARY_PATH to override the library search path will still be free to do
so.

I just installed unixodbc and tested a patch for this.  I'll commit it as
soon as I can get to CVS (I seem to be having connectivity problems today).
The patch isn't even as complicated as Merijn's suggestion...it's a two-line
change to configure.in (one for unixodbc, one for iodbc).

Cheers,
--nick

-----Original Message-----
From: bounce-freetds-145195 AT franklin.oit.unc.edu
[mailto:bounce-freetds-145195 AT franklin.oit.unc.edu] 
Sent: Thursday, October 03, 2002 2:05 PM
To: TDS Development Group
Subject: [freetds] RE: unixodbc library pickup


> From: Merijn Broeren [mailto:merijnb AT iloquent.com]
> Sent: October 3, 2002 12:41 PM
> 
> Please join the civilised world. Look at my libtdsodbc.so :
> 
> ldd /dist/fsf/PROJ/freetds/0.60/lib/libtdsodbc.so
>         libodbcinst.so.1 =>
> /dist/fsf/unixodbc/2.2.3/lib/libodbcinst.so.1
>         libsocket.so.1 =>        /usr/lib/libsocket.so.1
>         libnsl.so.1 =>   /usr/lib/libnsl.so.1
>         libc.so.1 =>     /usr/lib/libc.so.1
>         libdl.so.1 =>    /usr/lib/libdl.so.1
>         libm.so.1 =>     /usr/lib/libm.so.1
>         libthread.so.1 =>        /usr/lib/libthread.so.1
>         libmp.so.2 =>    /usr/lib/libmp.so.2
>         /usr/platform/SUNW,Ultra-Enterprise/lib/libc_psr.so.1

Merijn, 

Speaking as an illiterate barbarian, I can't tell you how rare is an
invitation from the civilised world.  I feel as though a velvet rope has
been lifted from my path!  Uncomprehending brute that I am, though, I think
I dimly perceive your point, which I suspect is valid, particularly given
your experience.  

If we can come to some agreement on a way that both obviates the need for
LD_LIBRARY_PATH and also supports it, I think that would be an avenue toward
an improvement.  Implemented, it certainly would have saved you time earlier
today.  

You clearly know your way around the autotools.  Is it possible to reconcile
your proposed fixes with Steve's point of view?  Or is this one of those
black/white things that has to be done one way or the other?  

In other words, if we do as you suggest, could we do so in a way that
doesn't interfere with the way Steve expects his Debian systems to run?  He
creates the Debian packages, see, and hardly represents the weirdest
environment known to FreeTDS, so it's not nothing to pay attention to him.  

I'd like to incorporate your ideas and knowledge into the autoconf files,
even if it means adding a --with-no-ldlibrary-path or somesuch to configure.
Best because most concrete would be if you posted a patch to the sourceforge
site.  That would be the sort of champagne glass worth putting down my stone
knife for.  ;-)  

Regards, 

--jkl



The information contained in this transmission may contain privileged and
confidential information and is intended only for the use of the person(s)
named above.  If you are not the intended recipient, or an employee or agent
responsible for delivering this message to the intended recipient, any
review, dissemination, distribution or duplication of this communication is
strictly prohibited. If you are not the intended recipient, please contact
the sender immediately by reply e-mail and destroy all copies of the
original message. Please note that for certain accounts we do not accept
orders and/or instructions by e-mail, and for those accounts we will not be
responsible for carrying out such orders and/or instructions. Kindly refrain
from sending orders or instructions by e-mail unless you have confirmed that
we accept such communications for your account. Please also note that to
satisfy regulatory requirements we review the outgoing and incoming e-mail
correspondence of staff members serving certain functions.



---
You are currently subscribed to freetds as: [Nicholas_Castellano AT acml.com]
To unsubscribe, forward this message to
$subst('Email.Unsub')


The information contained in this transmission may contain privileged and
confidential information and is intended only for the use of the person(s)
named above.  If you are not the intended recipient, or an employee or agent
responsible for delivering this message to the intended recipient, any
review, dissemination, distribution or duplication of this communication is
strictly prohibited. If you are not the intended recipient, please contact
the sender immediately by reply e-mail and destroy all copies of the
original message. Please note that for certain accounts we do not accept
orders and/or instructions by e-mail, and for those accounts we will not be
responsible for carrying out such orders and/or instructions. Kindly refrain
from sending orders or instructions by e-mail unless you have confirmed that
we accept such communications for your account. Please also note that to
satisfy regulatory requirements we review the outgoing and incoming e-mail
correspondence of staff members serving certain functions.