When using a 64-bit PPC64 kernel with the 32-bit userland, hmake-3.10 installs things in /usr/lib/hmake/ppc64-linux. This is apparently due to the fact that 'uname -m' returns ppc64, although ARCH=ppc in this particular case. The hmake-3.10 build procedure is probably using the output of 'uname -m' to create this directory tree, when it should be using something like $ARCH instead. As hmake is not apparently widely used anymore, this issue is somewhat moot. However, I will go ahead and enter this issue for tracking purposes, so that everyone knows that we are aware of it. I have given this a very low priority for being fixed, though.
I just stumbled on this bug; hadn't seen it before but this is timely nevertheless. We are seeing a fair amount of this kind of stuff either in configure scripts, Makefiles, or as it seems in this case, in scripts run during build. We are wrestling with a common solution but it seems each situation presents itself differently. I looked briefly at the hmake source and it seems the problem comes from: src/scripts/harch (which uses uname -m to determine "userland" arch. This is called by numerous scripts to set variables, which is likely the problem for the install path being incorrect. And it doesnt appear configure will honor ARCH, which would be preferable for a fix. I think you will have to resort to (in the ebuild) comparing the kernel arch and userland arc and if it differs, patching one of the scripts for hmake to set the arch to ppc. This should probably be in a conditional for only ppc right now. There are a ton of ways to do this. I'm also going to re-discuss with Spanky and company to see if we shouldn't have something in an eclass that will allow us to quickly assess if we are dealing with an environment where userland and kernel archs differ.
Haskell team, this bug is laying around for us on ppc64 32ul. the file I note in my previous comment does not accept or honor variables. it would seem the logical choice would be to patch that script or to patch configure (probably preferable) so that configure would set the arch within that script using one of the many arch variables we have available in eutils
How is one supposed to detect the userland arch? Can't we just patch hmake's harch script to figure it out properly. BTW, I note that ghc's configure script gets this wrong too and they decided it was too hard to fix since they're not being provided with enough information. http://hackage.haskell.org/trac/ghc/ticket/1717 So, what is the correct way to *detect* the arch on ppc64 with 32bit userland?
Duncan, if you can, find me on IRC today and we can hash through a plan. Ok, and to answer your question about ARCH detection. Here's Brent's opinion. Unless there are kernel modules built, arch detection should be done by $ARCH through the ebuild, and preferably passed to configure. Again. My opinion. What is killing us here is that an assumption is being made between kernel-arch and userland-arch. Unless there is actual kernel stuff going on, $arch should be sufficient. I'm thinking that the harch script could be patched out and configure could be easily modified to install properly then. I don't believe at this point that anuthing related to compilation is an issue. Let me peek at the configure script again and let's talk on IRC if you get a chance.
hmake doesn't seem to have any dependencies in the tree. Would it be safe for me to just "fix" this by dropping the keywords?
Nothing depends on hmake, and it has been superseded by cabal. In my opinion it should be removed from the tree.
Already masked
removed from tree as planned
