Re: broken: pkg-config and $includedir/gnome-2.0

[Havoc Pennington <hp redhat com>]

jacob berkman <jacob ximian com> writes: 
> this isn't it - because i do the the -L/gnome/lib when i put
> libgnomecanvas first.  the problem is that i get different (ie, one is
> broken) ordering of the -L lines depending on the order they are passed
> to pkg-config.

Note that this doesn't work in the general case, i.e. you can't do
something like this:

 -L /foo/lib -lblah -L /usr/lib -lbaz -L /foo/lib -lfoobar

Because the position of -L options with respect to -l options is not
significant. (I always thought it was, maybe no one else shared this
delusion, but it turns out that it isn't.)

So anyhow, you can only always prefer /foo/lib or always prefer
/usr/lib, you can't mix-and-match. Sort of makes pkg-config lamer than
it otherwise would be. Libtool probably handles this correctly...
I think you have to link to "/usr/lib/foo.so" instead of "-lfoo" to
do it, or something.


If I properly interpreted your mail, I guess what you're saying is
that flags originating from .pc files at the front of PKG_CONFIG_PATH
should always be placed before flags originating from .pc files at the
end of PKG_CONFIG_PATH. This would cause the -L flags to mirror
LD_LIBRARY_PATH, assuming that PKG_CONFIG_PATH corresponds to
LD_LIBRARY_PATH. Did I get that right?  Would it work to place the
command line package list in a canonical order based on
PKG_CONFIG_PATH order, before doing any work?

If I'm not confused I don't think this is a reliable/correct fix, but
it would probably increase the number of install situations that
happen to work.

Havoc