Checking for lib suffix broken

[Andras Mantia]

On Friday 31 March 2006 12:45, Stephan Kulow wrote:
> Am Donnerstag, 30. März 2006 21:58 schrieb Andras Mantia:
> > The first part seems to be OK, but the second part (changing the
> > default value from "auto" to "no") broke the entire meaning of this
> > autodetection. Now the autodetection will not be executed unless
> > you specify --enable-libsuffix=auto. Well, if you anyway specify a
> > flag, you could use "--enable-libsuffix=64" as well. If the problem
> > is that "kde-config --libsuffix" doesn't work in that cases,
> > kde-config should be fixed. But I don't see an error there, as if
> > shows me "64" even with my patch applied.
>
> The fix was for the other way around. If kde-config --libsuffix
> returns "", then it would default to auto and then the autodetection
> would detect the invalid lib64 dirs.

So the problem appears if one used --enable-libsuffix=no for kdelibs and 
nothing for the rest of the modules?

> So I understand you correctly, that kdelibs is broken for you, right?
> Because the fix was for kde!libs - I'm still not sure your fix would
> regress that situation again.


Yes, it was broken now, as I don't use any --enable-libsuffix, and 
before it installed everything to lib64 and now in lib and this broke 
building of all the other modules. 

If every KDE module/application relies on kde-config for the libsuffix, 
than I believe there must be a separate detection for kdelibs (or the 
meaning of "auto" should be different for kdelibs and everything else). 
I don't know how to make this distinction in acinclude.m4.in . 


Andras

-- 
Quanta Plus developer - http://quanta.kdewebdev.org
K Desktop Environment - http://www.kde.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20060331/f9ffe27c/attachment.sig>