Re: ct-lib unit tests link statically

> 
> ZIGLIO, Frediano, VF-IT wrote:
> > > See above.  datafmt is a ct-lib unit test.  readelf(1) shows
> > > the embedded
> > > RPATH.  The first part -- /usr/local/lib:/usr/pkg/lib -- 
> > > comes directly
> > > from LDFLAGS.  ldd(1) shows datafmt is dynmically linked to
> > > /usr/local/lib/libct.so.4.
> > >
> > 
> > I personally use LD_RUN_PATH environment to do the job and 
> it works for
> > me. > LD_RUN_PATH instructs ld/libtool to add some RPATHs.
> 
> Hi Freddy, 
> 
> I think I understand what you do, and for the first time I 
> understand why
> running "make" at the top of the tree does not build the unit tests. 
> (Although I don't understand what's in e.g. 
> src/ctlib/unittest/Makefile.am
> that excludes it from the recursive build.)  
> 
> When I link src/apps/* (except tsql) I want this RPATH:
> 
> 	/usr/local/lib:/usr/pkg/lib
> 
> When I link a unit test, I want (if any):
> 
> 	BUILD/src/API/.libs
> 
> (where BUILD is the build directory, obviously).  
> 
> We both want a special RPATH for unit tests.  You accomplish that by
> setting LD_RUN_PATH before building them.  Clever!  
> 

Well... Linux already put /usr/local/lib in default library include so I use LD_RUN_PATH
to add $HOME/install/lib for local home compilation/installations

> I want something more reliable than that, because I unit test 
> linkage must
> be foolproof for the thousands of people who'll never read 
> this thread or
> think about the issue.  
> 
> I'm happy with -static.  The only downside is during development: if
> you're testing new library functionality, you're required to 
> re-link the
> unit test every time you rebuild the library.  
> 

I think that if you don't find another way to do so... however I thought LD_RUN_PATH was
the right way...

> I'd be happier -- partly because you prefer it -- if the unit 
> tests could
> reliably use dynamic linking.  I'm not sure we can accomplish the
> "reliably" part, though:
> 
> 1.  We'd need to set LD_RUN_PATH in Makefile.am.  (Would that override
> LDFLAGS?)

Personally I set LD_RUN_PATH in my ~/.bashrc. It do not override LDFLAGS, it just add
paths to RPATH. Also my libtool recognize this setting and put local rpaths (unit test
ones) BEFORE.

> 2.  LD_LIBRARY_PATH overrides the built-in RPATH.  On most 
> Linux systems
> (and others, I'm sure), the unit tests would link to the installed
> library.  Every unit test would need a script to unset LD_LIBRARY_PATH
> (which might break searches for non-FreeTDS libraries).  

Mmm... LD_RUN_PATH override static linker RPATH while LD_LIBRARY_PATH override dynamic
linker paths. LD_RUN_PATH get embeded into executable, you can unset it after static
linking (here static linking is linking to produce the executable while compiling)

> 3.  Other things I know nothing about e.g. AIX.  
> 

Me too 

> Question: On your system LD_LIBRARY_PATH includes /usr/local, 
> right?  And
> you install FreeTDS to /usr/local?  If so, what use is 
> setting LD_RUN_PATH

I though that my system include /usr/local/lib in /etc/ld.so.conf but

$ cat /etc/ld.so.conf
include ld.so.conf.d/*.conf
/usr/X11R6/lib
/usr/lib/mysql
$ cat /etc/ld.so.conf.d/*
/usr/lib/mysql
/usr/lib/qt-3.3/lib

:(

perhaps configure script detect that /usr/local/lib is not included and use RPATH ??
Personally I don't have any executable installed that require libraries in /usr/local/lib.
I use system prefix or compiled RPMs or in a HP-UX environment tsql (which is statically
linked).

> when you build the unit tests?  LD_LIBRARY_PATH will cause the runtime
> linker to override the embedded RPATH.  ldd(1) should show 
> your unit test
> linking to /usr/local. 
> 

I'll test an installation to /usr/local...

$ make install
...
$ set | grep LD
LD_LIBRARY_PATH=/home/winnt/fziglio/install/lib
LD_RUN_PATH=/home/winnt/fziglio/install/lib
$ cd src/dblib/unittests/
$ file t0001
t0001: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), dynamically linked (uses
shared libs), for GNU/Linux 2.6.9, not stripped
$ ldd t0001
        linux-gate.so.1 =>  (0xb7fdd000)
        libsybdb.so.5 =>
/home/winnt/fziglio/cpp/freetds/freetds83/src/dblib/.libs/libsybdb.so.5 (0xb7f6c000)
        librt.so.1 => /lib/librt.so.1 (0x00349000)
        libgssapi_krb5.so.2 => /usr/lib/libgssapi_krb5.so.2 (0x00687000)
        libgnutls.so.13 => /usr/lib/libgnutls.so.13 (0x06a2d000)
        libpthread.so.0 => /lib/libpthread.so.0 (0x00d98000)
        libc.so.6 => /lib/libc.so.6 (0x00b29000)
        /lib/ld-linux.so.2 (0x00ae4000)
        libkrb5.so.3 => /usr/lib/libkrb5.so.3 (0x005a7000)
        libk5crypto.so.3 => /usr/lib/libk5crypto.so.3 (0x00631000)
        libcom_err.so.2 => /lib/libcom_err.so.2 (0x0067d000)
        libkrb5support.so.0 => /usr/lib/libkrb5support.so.0 (0x006df000)
        libdl.so.2 => /lib/libdl.so.2 (0x00b01000)
        libresolv.so.2 => /lib/libresolv.so.2 (0x00592000)
        libz.so.1 => /usr/lib/libz.so.1 (0x00b14000)
        libgcrypt.so.11 => /usr/lib/libgcrypt.so.11 (0x065f1000)
        libgpg-error.so.0 => /usr/lib/libgpg-error.so.0 (0x00adb000)
        libnsl.so.1 => /lib/libnsl.so.1 (0x00330000)

still point to local library, not installed one

> I think runtime linkage is too mysterious and quirky to use with unit
> tests.  Static linkage is reliable and does the job.  

Yes, it produce big executable but surely no override is possible :)

> Definitely we want
> statically linked unit tests for general distribution.  
> 
> For development purposes, perhaps we could handle #1 above in 
> Makefile.am
> and have a configure option --dynamic-link-unittests.  That might be
> convenient, if you think it's worth the effort.  
> 

bye
  freddy77

_______________________________________________
FreeTDS mailing list
[email protected]
http://lists.ibiblio.org/mailman/listinfo/freetds