tech-pkg archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

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



    Date:        Wed, 22 Sep 2010 13:01:47 +0700
    From:        Robert Elz <kre%munnari.OZ.AU@localhost>
    Message-ID:  <27587.1285135307%epsilon.noi.kre.to@localhost>

I have been investigating this further...   (for anyone on tech-pkg but
not on pkgsrc-users this is all an attempt to find the underlying cause
why the pixman upgrade broke linking/building of lots of other stuff).

This from the .work.log of the gtk2 build is where I was last time...

  | [*] ...... -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

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

and have gotten just about as far as I can I think...   I know now that
the root cause of this (for configure) is that the "wrong" info is handed
to configure via LDFLAGS in its environment.

That is, I made the configure script dump its env right at its start
(before it has had a chance to alter anything), and in that I see ...

LDFLAGS=-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

That is clearly where the incorrect order is originating.   However I can't
find exactly where in pkgsrc (and/or all the scripts it runs) where LDFLAGS
is set, or by what, or where the data used to set it comes from, so I think
this now needs assistance from someone who really understands pkgsrc.

About the only other oddities that I have noticed, are that in libxcb.so
(which is one of the libraries in gtk2's .buildlink/lib directory) the
RPATH is backwards (/usr/X11R7/lib:/usr/pkg/lib) which makes no sense as
a setting at all to me.

All the other .so files that gtk2 links against either have only
/usr/pkg/lib or only /usr/X11R7/lib or both, with /usr/pkg/lib before
/usr/X11R7/lib (all three of which are rational).

Does anyone know why libxcb (from pkgsrc, netbsd 5 doesn't have it in
base) would have the RPATH setting backwards?

Might that be contributing to the problem being experienced?

And (less likely to be relevant) for current issues, but odd anyway,
I see in .buildlink/lib/pkgconfig/pangox.pc the following ...

Libs: -Wl,-R${libdir} -L${libdir} -lpangox-1.0  -L/usr/X11R7/lib 
-R/usr/X11R7/lib -lX11 -Wl,-R/usr/X11R7/lib

That has the libraries in the right order (so do the other couple of .pc
files that reference both) - the oddity is the -R arg sitting there.
What's that one about?   That looks like a (harmless) bug to me.

Can anyone suggest what I should look for next to try and determine
why pkgsrc is building the -Wl,-R args for the LDFLAGS it puts in the env
with the directories in the wrong order?   (Especially given that it gets
the -L arg order correct).

Can anyone suggest any reason why we would ever want /usr/X11R7/lib
before /usr/pkg/lib?   To me that makes no sense - if pkgsrc is installing
a library with the same name as something in the base system (wither in X11R7
or just in /usr/lib) then it must intend that new library to be used in
preference to the (typically older) system one, mustn't it?

kre




Home | Main Index | Thread Index | Old Index