Re: [gentoo-amd64] Re: my amd64 system is not recognised at linux-*-64

[Markos Chandras]

On Friday 24 April 2009 08:40:50 Duncan wrote:
> Markos Chandras <hwoarang@g.o> posted
> 200904231600.12638.hwoarang@g.o, excerpted below, on  Thu, 23 Apr
>
> 2009 16:00:07 +0100:
> > I asked about this on #gentoo-amd64, but I ll be quite busy and I might
> > miss the answer.
>
> Looks like you got a workaround for the ebuild from another subthread,
> tested and unmasked it, but that appears to be what it was, a
> workaround.  Nobody explored the why.
>
> Well, I'm not an expert by any means and the following guess is just what
> it says on the label, a guess, without properly delving into the qmake
> internals, but maybe this will provide a place to start exploring, for
> you or anyone else interested.
>
>
I tried to figure out why but I couldnt. I also contacted upstream but they 
were unable to help me more. The workaround is quite safe and doent causes any 
further problems :)
> > So
> >
> > I have a problem with qt-creator installation on amd64
> >
> > Take a look on this code
> >
> > linux-*-64 {
> >     IDE_LIBRARY_BASENAME = lib64
> > } else {
> >     IDE_LIBRARY_BASENAME = lib
> > }
> >
> > According to this, when the system is amd64, libraries should be
> > installed under lib64/ directory, else they will be installed on lib/
> > directory.
>
> Makes sense, but what is it testing there?
>
> The first thing that reminded me of was the CHOST/CBUILD/CTARGET set of
> vars from the GNU make build system, with CHOST set in the (cascaded)
> profile make.defaults (profiles/arch/amd64/make.defaults for 2008.0/amd64
> profile users).
>
> But, CHOST isn't it as the order is wrong.  My CHOST is
> x86_64-pc-linux-gnu according to emerge --info (and following the
> cascading profiles, from the file mentioned above), and that's not going
> to match linux-*-64 at all.  Since CHOST is standardized, that can't be
> what they're testing against.
>
> Well, I'm not familiar with qmake (which I got from the tarball README,
> tho the ebuild would have had it too), and I'm not going to try to
> explain how it gets from here to there as I don't know, but the best
> match for the above pattern I could come up with is the following:
>
> 1) equery belongs qmake says it's part of the qt-core-4.5.0 package, here
> (and also part of qt-3.3.8b-r1, but that's beside the point).
>
> 2) Looking at equery files qt-core, the following jumps out due to the
> pattern, which matches the one above:
>
> /usr/share/qt4/mkspecs/linux-*-64 , with * being the three: ecc, c++,
> icc .
>
> So, a reasonable theory might be that it's matching the mkspecs,
> expecting a pattern similar to linux-*-64 for our case.  How it comes up
> with that is as they say, "an exercise for further research", reading up
> on qmake, it's MAKE vars (or whatever qmake calls them), etc.
>
> 3) However, I found the following symlink, also from the qt-core package,
> also of interest:
>
> /usr/share/qt4/mkspecs/default -> linux-g++-64
>
> 4) So a further supposition, given the failure of the test above, may be
> that it's ultimately using mkspecs/default instead of linux-g++-64
> specifically.  If the test was on the symlink itself (not dereferenced)
> and not on what it pointed to, that would necessarily cause it to fail
> the match.
>
> So without knowing much at all about how qmake functions and where it
> gets its config such as the bit it's testing above, that's my working
> theory and why I'd /guess/ it's failing the match.  Qt  based package
> maintainers and devs would of course be expected to know (or at least
> know where to look up when necessary) rather more about qmake internals,
> and be able to take it from there, proving or disproving my admittedly
> rather badly informed /guess/.
>
> > The thing is that on my amd64 system, they install on lib/ directory. Do
> > you have any ideas why it fails to pick the right directory?
> >
> > My features are
> >
> > Eternity ~ # portageq envvar FEATURES buildpkg ccache distlocks
> > fixpackages metadata-transfer parallel-fetch preserve-libs protect-owned
> > sandbox sfperms strict unmerge-orphans userfetch
> >
> >
> > I tried to add multilib on FEATURES but it didnt solve this issue
>
> As others have said, on Gentoo, multilib isn't something you should be
> messing with directly.  It's part of your profile.  To change it, you
> change your profile (and deal with all that entails).  Trying to do
> otherwise, if it does anything at all, "may have unintended consequences"
> as they say. =:^)

qmake will read the QMAKESPEC variable. This variable is 'usually' set as 
/usr/share/qt4/mkspecs/default which is a symlink to the actual mkspec. So my 
symlink is right

That is

Eternity ~ # ls -la /usr/share/qt4/mkspecs/|grep default
lrwxrwxrwx  1 root root   12 2009-04-23 19:33 default -> linux-g++-64

So the initial code should work flawlessly. But it doesnt. So either the .pro 
file of qt-creator is broken or our ( as in Qt team ) qmake is broken as well.
qmake doesnt seem to read QMAKESPEC . Of course it needs further investigation 
but it is rather complicated to do this right now

-- 
Markos Chandras (hwoarang)
Gentoo Linux Developer
Qt/KDE/Sunrise/Sound
Web: http://hwoarang.silverarrow.gr