portupgrades fail because of missing /usr/local/lib/liblzma.la

[b. f.]

> On my 8.2-System (amd64, kernel & system updated two days ago) I run
> into a nasty problem updating my ports:
>
> Ports that depend on "liblzma" fail to build with the following error:
>
> "/usr/local/lib/liblzma.la: No such file or directory"
>
> AFAIK, the xz-libraries are not part of the base system; there is
> indeed a /usr/lib/liblzma*, but why doesn't the build process for the
> ports recognize it and insists on having the libraries in
> /usr/local/lib?
>
> When installing the xz-libraries from the ports, i.e.
>
> pkg_add -r -f xz
> and
> portupgrade -o archivers/xz lzmautils\*
>
> upgrading my ports works, but this truly can't be the correct
> solution, esp. since building xz out of the ports tree ins't
> supported:
>
> # pwd
> /usr/ports/archivers/xz
> # make
> ===>  xz-5.0.3 is already in the base system.
> *** Error code 1
>
> Stop in /usr/ports/archivers/xz.
> #
>
> So here are my questions?
>
> o) Why doesn't the build process of ports recognize the xz-libraries
> in /usr/lib? (BTW, not even "make deinstall && make clean && make
> install" helps)

It is difficult to diagnose the problem when we do not know _which_
ports are failing, and we have no transcripts and config.logs from the
failed builds.

Your ports should recognize and use the lzma libraries from the base
system, but It seems that one of your builds is polluted.  When you
build ports on a system that already has many packages installed, you
are not replicating the conditions under which packages are built on
the FreeBSD package-building and test cluster, because those machines
start builds in a clean sandbox, with only the registered build
dependencies present.  So occasionally a problem like yours occurs,
where a build fails locally when it succeeds on the test machines.
Usually, but not always, such failures can be prevented by following a
procedure like that described in the portmaster(1) page, under the
heading: "Using portmaster to do a complete reinstallation of all your
ports", that involves deinstalling _all_ ports _before_ rebuilding
them.  However, many people aren't this thorough in their updating,
and even when they are, there are a few problems that can still occur.

> o) What can I do to get ports recognize the correct location of the
> xz-libraries?

As I wrote above, some more information would help.  I'm guessing that
you have a port that (unfortunately) uses libtool to perform linking,
and has an erroneous /usr/local/lib/lzma.la entry in a libtool archive
file (*.la), or is using some combination of uncommon  linker flags
and sloppy use of -L/usr/local/lib.  Does a search like:

fgrep -e lzma -nHr /usr/local/lib --include='*.la'

yield any results?  If you see any references in a libtool archive to
the nonexistent "/usr/local/lib/liblzma.la", try removing and then
rebuilding the port that owns that libtool archive -- you should be
able to determine the port by running "pkg_info -W" with the full path
of the libtool archive as an argument.

Also, do you have any garbage in /usr/local?:

--Does "pkg_info -ga" reveal any corrupted or missing files?
--Is there any output that you cannot account for from a shell script
like the following?:

#!/bin/sh
l=${LOCALBASE-/usr/local}
t=${TMPDIR-/tmp}
lf=`mktemp ${t}/lf.XXXXXX` || exit 1
lpf=`mktemp ${t}/lpf.XXXXXX` || exit 1
find ${l} -type f | sort > ${lf}
pkg_info -qaL | sort -u > ${lpf}
echo "the following files in ${l} not claimed by any installed package:"
comm -23 ${lf} ${lpf}
rm ${lf} ${lpf}

--Do you have any libraries in compat directories that you really don't need?
--Do you have any installed root or leaf ports that you don't need?

If so, consider removing all of the above.

b.