Re: math/R failing to install

[David Holland <dholland-pkgtech%netbsd.org@localhost>]

On Mon, Jun 27, 2016 at 05:38:13PM -0600, Brook Milligan wrote:
 > >> On Sat, Jun 25, 2016 at 10:26:43AM -0600, Brook Milligan wrote:
 > >>> /usr/pkg/lib/libxcb-shm.so.0.0.0:
 > >>> 	-lxcb.2 => /usr/X11R7/lib/libxcb.so.2
 > >>> 	-lXau.7 => /usr/X11R7/lib/libXau.so.7
 > >>> 	-lgcc_s.1 => /usr/lib/libgcc_s.so.1
 > >>> 	-lc.12 => /usr/lib/libc.so.12
 > >>> 	-lXdmcp.7 => /usr/X11R7/lib/libXdmcp.so.7
 > >> 
 > >> So um... is there a reason you're mixing native and pkgsrc X? Some
 > >> combinations of that have been made to work in the past, but in
 > >> general it's a bad idea.
 > 
 > So the problem comes down to the behavior of graphics/cairo.  When
 > the x11/libxcb and x11/xcb packages were installed, the cairo
 > package picks them up and ends up linking to a chimera of
 > libraries, some from /usr/X11R7/lib and some from /usr/pkg/lib. 

Right, once you mix native and pkgsrc X packages you get a mix of
depends and a mix of libraries.

In theory even if pkgsrc libxcb is installed it shouldn't be used
unless you have PREFER settings to that effect or the native package
is too old to be used (-7's isn't). I'm not absolutely sure about that
(especially with X packages where there are a lot of special cases and
gotchas)... but in any event this isn't a problem with cairo as such
because it's all from the builtin framework.

(Note that while libxcb is an X library and part of native X, so you
shouldn't have it installed, x11/xcb seems to be something else
unrelated and should be harmless.)

Keep in mind that nowadays if package A depends on package B, if
something causes the builtin version of B to not be used then the
builtin version of A won't be used either regardless of what its
builtin.mk might think.

So I guess the first thing to check is if you have PREFER settings
you've forgotten about that might cause this. Failing that, the goal
is to find out which X package(s) are failing to be found as builtin
(or which are being found but pkgsrc isn't using) -- those will be the
ones at the root of the dependence graph as shown with pkg_info -n and
make show-installed-depends.

(And if pkg_info -n and make show-installed-depends disagree, that's a
sign the package in question should be recompiled; among other things
this can happen if you update the base system such that the set of
acceptable builtin packages changes.)

When you find the root(s), for example let's suppose the root is
libXmu (not very likely) you may find that IS_BUILTIN.libXmu is yes
but USE_BUILTIN.libXmu is no; in that case the question is why it's
declining to use the native version. (To check these, use make
show-var VARNAME=whatever from a depending package; for libXmu, for
example, that might be libXaw.) This will probably require some
debugging.

I'm guessing the way you got to this point is by updating to -7 from
-5 (where by late in the cycle you would get libxcb and some other
stuff from pkgsrc because native X was too old) without rebuilding
everything depending on X. :-/

I wouldn't be entirely surprised if there's also something broken
happening somewhere. For example, right now in my current pkgsrc tree,
from x11/libxcb, if I do
   make show-installed-depends USE_BUILTIN.xproto=no
I get:
   libXau>=1.0 =>
which is definitely wrong -- libxcb depends on libXau and libXdmcp,
and both of those have the same depends; so this should print neither
or both of them but not half and half.

-- 
David A. Holland
dholland%netbsd.org@localhost