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

[Robert Elz <kre%munnari.OZ.AU@localhost>]

  | On Mon, Sep 20, 2010 at 10:43:32AM +0700, I wrote:
  |  > Is there any chance that the transform might alter the order of the
  |  > cc args?

    Date:        Tue, 21 Sep 2010 06:56:51 +0000
    From:        David Holland <dholland-tech%netbsd.org@localhost>
    Message-ID:  <20100921065651.GA29802%netbsd.org@localhost>

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

There is definitely something odd going on here, and this looks to be
the source of the problem.

The commands as they're reported in pkgsrc's .work.log ...

[*] ...... -L/usr/pkg/lib -L/usr/X11R7/lib -Wl,-R/usr/X11R7/lib -L/usr/lib 
-Wl,-R/usr/lib -Wl,-R/usr/pkg/lib -pthread -L/usr/pkg/lib/python2.6/config 
-Wl,-R/usr/pkg/lib/python2.6/config conftest.c -Wl,-R/usr/pkg/lib -pthread 
-Wl,-R/usr/X11R7/lib -L/usr/pkg/lib -L/usr/X11R7/lib -lpangocairo-1.0 -lcairo 
-lpangoft2-1.0 -lpango-1.0 -lm -lfreetype -lz -lfontconfig -lgobject-2.0 
-lgmodule-2.0 -lgthread-2.0 -lglib-2.0 -lintl
<.> ...... -L/pkg_comp/obj/pkgsrc/x11/gtk2/5/.buildlink/lib 
-L/pkg_comp/obj/pkgsrc/x11/gtk2/5/.x11-buildlink/lib -Wl,-R/usr/X11R7/lib 
-Wl,-R/usr/pkg/lib -pthread 
-L/pkg_comp/obj/pkgsrc/x11/gtk2/5/.buildlink/lib/python2.6/config 
-Wl,-R/usr/pkg/lib/python2.6/config conftest.c -pthread  -lpangocairo-1.0 
-lcairo -lpangoft2-1.0 -lpango-1.0 -lm -lfreetype -lz -lfontconfig 
-lgobject-2.0 -lgmodule-2.0 -lgthread-2.0 -lglib-2.0 -lintl

Notice that the -L args are in the right rode, but the -Wl,-R args are
the order that we don't want.

I replaced /usr/bin/ld with a script that just echoed its args (then ran
the original ld, now renamed), and what it said it is being handed is...

/usr/bin/ld -dc -dp -e __start -dynamic-linker /usr/libexec/ld.elf_so -o 
conftest /usr/lib/crt0.o /usr/lib/crti.o /usr/lib/crtbegin.o 
-L/pkg_comp/obj/pkgsrc/x11/gtk2/5/.buildlink/lib 
-L/pkg_comp/obj/pkgsrc/x11/gtk2/5/.x11-buildlink/lib 
-L/pkg_comp/obj/pkgsrc/x11/gtk2/5/.buildlink/lib/python2.6/config 
-R/usr/X11R7/lib -R/usr/pkg/lib -R/usr/pkg/lib/python2.6/config 
/var/tmp//cccRcxbK.o -lpangocairo-1.0 -lcairo -lpangoft2-1.0 -lpango-1.0 -lm 
-lfreetype -lz -lfontconfig -lgobject-2.0 -lgmodule-2.0 -lgthread-2.0 
-lglib-2.0 -lintl -lgcc -lgcc_eh -lpthread -lc -lgcc -lgcc_eh /usr/lib/crtend.o 
/usr/lib/crtn.o

Again, that has the -L args in the right order, and the -R's in the wrong
order.

To verify that this causes the problem, I had my ld wrapper, simply force
-L/usr/pkg/lib -R/usr/pkg/lib before all other args (and yes, I know that
probably I should have used the .buildlink for the -L, but by this stage
it can hardly matter), and with that in place (and without my earlier
patch attempt) gtk2 configured properly.

I haven't yet verified that it builds, and if it does, whether the version
that results avoids the undefined symbols from a small handful of programs
that had problems with the way I bashed through the problem a couple of
days ago.   That's coming.

I wondered if someone might know why the -Wl,-R args are ending up in the
wrong order there - they appear to be sane when obtained from pkg_config
the way gtk2's configure script fetches them

        pkg_config --libs pango pangocairo

results (from the .tools/bin/pkg_config) ...

-Wl,-R/usr/pkg/lib -pthread -Wl,-R/usr/X11R7/lib -L/usr/pkg/lib 
-L/usr/X11R7/lib -lpangocairo-1.0 -lcairo -lpangoft2-1.0 -lpango-1.0 -lm 
-lfreetype -lz -lfontconfig -lgobject-2.0 -lgmodule-2.0 -lgthread-2.0 
-lglib-2.0 -lintl  

which looks right to me (at least the order looks right).  That string is
prepended to any other libs the configure script may have already determined
(LIBS="$PANGO_LIBS $LIBS" approx) so the primary order there ought to be
retained.

Then it tries its cc (via .wrapper/bin/cc I assume) with the flags,
files, and this set of libs, and what gets through the wrappers is
as above - that initial "-Wl,-R/usr/pkg/lib" seems to have vanished.

mrg%eterna.com.au@localhost said:
  |  i'm not sure exactly understand the question though.  are there two shlibs
  | being linked?  or just two with the same name in different subdirs of the
  | link path? 

There are (as above) lots of libs being linked.   The problem is two with
the same name in different dirs in the link path (which are different versions
of the same basic library, old in X11R7/lib and new in pkg/lib).

We need to always find the new one.

mrg%eterna.com.au@localhost said:
  | ah, it has been pointed out that -rpath and -rpath-link affect the
  | finding of shlibs referenced by other shlibs.

and this appears to be the problem precisely.   The library with two
versions isn't mentioned explicitly anywhere, it is a dependency of
another library (the one with two versions is libpixman-1 - which isn't
in any of the lists above, anywhere - referencing it explicitly "solves'
the problem, kind of, but that then would need to happen every time).

What I think we need to discover now, is just what piece of brokenness
in pkgsrc's transforms or wrappers is mangling the library list (or
perhaps it was being built incorrectly in one of libpixman-1 or the
pangocairo library (or one of those))  ??

Anyone have any more suggestions for things to look at?

kre