[Digikam-users] Error in compiling from svn

[Jakob Østergaard]

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
> linking.

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.

-- 
Best regards,
   Jakob Oestergaard