Sean,
thank you, I wrote the list last week about failing zfs-snapshots
on a new client install on Solaris 10/x86. gtar worked fine, the
server (server!=client) worked find and had no changes.
Following your lead I ran # ldd /usr/local/etc/libexec/amandad
an found that I did have some linkage against /usr/local/libexec/
rather than /usr/local/libexec/amanda/
Reinstalling on the client I seem to have cleared that up
# rm /usr/local/libexec/libama* [not pretty but effective]
and then # gmake install (oh, I actually used # make, well,
it ran).
Anyway, I can now run # amcheck cleanly against the client
even when zfs-snapshot is used as a dump-type on that client.
thanks,
Brian
On Sun, Jul 25, 2010 at 04:10:23PM -0400, Sean Walmsley wrote:
> We recently had a difficult to solve problem installing Amanda 3.1.1
> from source on Solaris 10 x86. The problem turned out to be an older
> amanda library version being picked up by the 'gmake install'
> (but not configure/gmake/gmake check) process from /opt/sfw
> (i.e. an Amanda install that is part of the Solaris companion CD).
> Forgot about that one!
>
> Once we removed the older version and recompiled/reinstalled, things
> started working.
>
> Our questions is: why wasn't this problem picked up by our
> "gmake check"?
>
> Digging, it turns out that the libraries created under the
> SOURCE directory were fine, i.e. using "ldd" on libamxfer.so
> correctly shows it including "libamanda-3.1.1.so" from our
> source tree. The INSTALLED libamxfer.so however, was
> attempting to include "libamanda-2.5.2p1.so" from
> /opt/sfw/lib. We were careful to include the same
> link (-L) and runtime (-R) library locations so we weren't
> expecting this.
>
> If the gmake install process is going to relink libraries, shouldn't it
> always search for AMANDA libraries in the AMANDA installation
> directory first? Similar, in other words, to how the libraries
> compiled under the source tree seem to search for amanda libraries
> under the source tree first. If not, you're testing one thing and
> then getting something that might be quite different.
>
> Would explicitly including the install directory as part of
> the runtime library path in the configure call
> (e.g. LDFLAGS='-R <prefix dir>/lib/amanda') prevent this problem
> in future? Is this recommened?
>
> Thanks for any insight you can provide (well, besides the obvious
> suggestion to not leave older versions of Amanda about!).
>
> In case it helps, our configure call was:
>
> ./configure --with-group=sys \
> --without-amperldir \
> --with-user=amanda \
> --without-ipv6 \
> --enable-threads=solaris \
> --disable-nls \
> --disable-s3-device \
> --with-bsdtcp-security \
> --with-readline \
> --with-gnutar=/usr/sfw/bin/gtar \
> --with-gnuplot=/opt/sfw/bin/gnuplot \
> --with-index-server=thor1 \
> --prefix=${AMBASE} \
> --with-config=${AMCFG} \
> --with-configdir=${AMBASE}/etc \
> --with-tmpdir=/tmp/amanda/${AMCFG} \
> --with-gnutar-listdir=${AMBASE}/var/${AMCFG}/gnutar-lists \
> MAKE=/usr/sfw/bin/gmake \
> EGREP=/usr/sfw/bin/gegrep \
> CC=/home/compilers/SUNWspro/bin/cc \
> CPPFLAGS='-I/opt/sfw/include' \
> LDFLAGS='-L/usr/sfw/lib -L/opt/sfw/lib -R/usr/sfw/lib -R/opt/sfw/lib' \
> MTX="${AMBASE}/MTX/sbin/mtx"
>
>
>
> Sean Walmsley
>
---
Brian R Cuttler brian.cutt...@wadsworth.org
Computer Systems Support (v) 518 486-1697
Wadsworth Center (f) 518 473-6384
NYS Department of Health Help Desk 518 473-0773
IMPORTANT NOTICE: This e-mail and any attachments may contain
confidential or sensitive information which is, or may be, legally
privileged or otherwise protected by law from further disclosure. It
is intended only for the addressee. If you received this in error or
from someone who was not authorized to send it to you, please do not
distribute, copy or use it or any attachments. Please notify the
sender immediately by reply e-mail and delete this from your
system. Thank you for your cooperation.
