Re: travails of the pixman upgrade [Was: Is pango still broken? (vim-gtk2 won't build)]

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

On Mon, Sep 20, 2010 at 10:43:32AM +0700, Robert Elz wrote:
 > The args for /usr/pkg/lib (-L and -Wl,R) are both before the
 > corresponding args for /usr/X11R7/lib so any rational expectation
 > would be that the libpixman-1 in /usr/pkg/lib (or .buildlink/lib if
 > something is transforming it) ought to be the one that is found -
 > but it clearly isn't.
 > 
 > Is there any chance that the transform might alter the order of the
 > cc args?

The buildlink transforms do (or have done in the past) a number of
unkosher things, and that includes, sometimes, reordering stuff in
ways that isn't always harmless. (It's supposed to be harmless, but
that doesn't always work out...)

Check the wrapper logs?

 > Good question.   Maybe someone who understands the toolchain can explain
 > how a library gets selected when given to a cc (gcc) command line as -lfoo
 > and libfoo-*.so exists in two different directories, both of which are
 > specified in -L args (and -Wl,R args of course.) ??

That part's easy; the -L args form a search path, which is ordered.

So in theory do -Wl,-R args, but it seems to be readily possible by
scrambling these to create binaries that are linked against the
library image in one directory but automatically load the other one at
runtime.

In particular, I have

   libfoo.so.0 in /tmp/test/lib
   libbar.so.0 in /tmp/test/lib
   libfoo.so.0 in /tmp/test/lib2 (which comes from a different source file)

and a test program, and at least in the configuration where libbar is
linked with

   -L/tmp/test/lib2
   -Wl,-R,/tmp/test/lib2
   -lfoo

(to get the alternate libfoo) and the test program is linked with

   -L/tmp/test/lib -L/tmp/test/lib2
   -Wl,-R,/tmp/test/lib2 -Wl,-R,/tmp/test/lib
   -lbar

(with the order of the -R path backwards) it links against the libfoo
in /tmp/test/lib2, which can be verified by adding an extra unresolved
symbol there and watching the link fail, but at runtime it takes both
library images images from /tmp/test/lib, which can be verified by ldd
and by having the two libfoo images print different messages.

This seems thoroughly broken to me, but maybe someone else can make
sense of it.

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