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!  

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'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?)
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).  
3.  Other things I know nothing about e.g. AIX.  

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
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 think runtime linkage is too mysterious and quirky to use with unit
tests.  Static linkage is reliable and does the job.  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.  

Regards, 

--jkl