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

[Duncan]

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.

> 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. =:^)

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman