[Digikam-users] Error in compiling from svn
joe at evalesco.com
Mon Jun 25 08:44:25 BST 2007
On Sunday 24 June 2007, Paweł Marciniak wrote:
> Arnd Baecker wrote:
> > Due to a bug, in my opinion, the wrong kexiv2 is found.
> > This has been discussed quite a bit.
> > See for example,
> > http://mail.kde.org/pipermail/digikam-users/2007-June/003687.html
> > for a hack
> Thanks for your hint. I applied the script proposed in that thread
> (changing the order in PKG_CONFIG_PATH), but it didn't solve my
> problem. I still get the same error. Note that, in the thread you
> mentioned, the problem appears at the stage of configuring digiKam.
> In my case ./configure is successful and the problem shows up when
The configure script uses pkg_config to determine if your library is
good enough to link with.
The pkg_config program uses the PKG_CONFIG_PATH when it searches for
library versions - which library it finds first depends on the
contents of PKG_CONFIG_PATH.
The linker, however, uses the linker path, not PKG_CONFIG_PATH, when
resolving which library to actually link with.
In my situation (the mail that was referred to above), pkg-config found
the wrong library and configure wouldn't run - but when forced,
everything would work because the linker used the right library (and
would have done so, no matter what PKG_CONFIG_PATH held).
In your sitaution, pkg-config finds the right library, configure thinks
everything will work, but the linker path is not correctly set up and
therefore the actual link fails. In this situation, configure is also
wrong (like in my situation), but you're seeing a false positive
whereas I was a false negative. The problem is the same though;
pkg_config and the linker not agreeing on the library search path.
In conclusion, repeating what I've said earlier; the concept of having a
PKG_CONFIG_PATH is fundamentally broken. It can never work. If
pkg_config is queried for library version numbers (as it is) then it
*must* use the linker path (like the linker does) to resolve libraries.
If PKG_CONFIG_PATH was set correctly (which it isn't) then it would be
identical to the linker path. There is *no* valid scenario (in which
pkg-config is used for library version resolution) that I can imagine,
where the PKG_CONFIG_PATH would differ from the linker path. None what
so ever. Any such scenario would mean, that one would want pkg_config
to deliberately lie about which library would be linked - which you
don't. If you don't care about the library versions, then it is easier
to just not ask pkg_config than (mis-)configuring it to lie about it.
I understand that pkg_config can do other things than library
resolution. In those situations I claim my argument still holds; when
resolving include files pkg_config should use whatever path the
compiler uses for that, etc.
In short; as long as PKG_CONFIG_PATH exists, these problems will exist.
Any change to how PKG_CONFIG_PATH is set, is a workaround, not a fix.
It is not the *value* of PKG_CONFIG_PATH that is wrong, it is the
concept of its existance.
More information about the Digikam-users