Skip to Content.
Sympa Menu

freetds - Re: [freetds] ct-lib unit tests link statically

freetds AT lists.ibiblio.org

Subject: FreeTDS Development Group

List archive

Chronological Thread  
  • From: "ZIGLIO, Frediano, VF-IT" <Frediano.Ziglio AT vodafone.com>
  • To: "FreeTDS Development Group" <freetds AT lists.ibiblio.org>
  • Subject: Re: [freetds] ct-lib unit tests link statically
  • Date: Thu, 10 Jul 2008 17:23:08 +0200

>
> 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

Attachment: smime.p7s
Description: S/MIME cryptographic signature




Archive powered by MHonArc 2.6.24.

Top of Page