Summary: | x11-misc/xorg-cf-files-1.0.3 does not support multilib-nosymlink | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Nathan Phillip Brink (binki) (RETIRED) <binki> |
Component: | [OLD] Development | Assignee: | Gentoo X packagers <x11> |
Status: | RESOLVED FIXED | ||
Severity: | normal | CC: | esigra |
Priority: | High | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Bug Depends on: | |||
Bug Blocks: | 306835 | ||
Attachments: |
/tmp/emerge--info.txt
/tmp/transfig-3.2.5d-build.log files/xorg-cf-files-1.0.3-libdir.patch xorg-cf-files-1.0.3.ebuild-multilib-nosymlink.patch Respect LIBDIR for multilib |
Description
Nathan Phillip Brink (binki) (RETIRED)
2010-10-31 05:41:15 UTC
Created attachment 252635 [details]
/tmp/emerge--info.txt
Created attachment 252637 [details]
/tmp/transfig-3.2.5d-build.log
An example of xorg-cf-files causing imake to fail on a multilib-nosymlink system.
Created attachment 252639 [details]
files/xorg-cf-files-1.0.3-libdir.patch
Patches the files distributed with x11-misc/xorg-cf-files to respect multilib systems in general.
Created attachment 252641 [details] xorg-cf-files-1.0.3.ebuild-multilib-nosymlink.patch Upgrade to EAPI=2, move some stuff into src_prepare(), apply the libdir patch for bug 343461, inherit all used eclasses to ensure that functionality doesn't change. Is this thing even supported nowadays? (In reply to comment #5) > Is this thing even supported nowadays? If bug 289296 is fixed (which requires the ``resolved'' bug 290424 to be fixed first), then this bug may be resolved WONTFIX/INVALID. If your question about support concerns multilib-nosymlink, then I have to comment that multilib-nosymlink is useful for discovering bad situations where 32-bit code wrongly ends up using /usr/lib (and thus, by way of symlink, /usr/lib64). (In reply to Nathan Phillip Brink (binki) from comment #6) > (In reply to comment #5) > > Is this thing even supported nowadays? > > If bug 289296 is fixed (which requires the ``resolved'' bug 290424 to be > fixed first), then this bug may be resolved WONTFIX/INVALID. > > If your question about support concerns multilib-nosymlink, then I have to > comment that multilib-nosymlink is useful for discovering bad situations > where 32-bit code wrongly ends up using /usr/lib (and thus, by way of > symlink, /usr/lib64). This bug is still there and it hits more exotic multilib systems like mips64el with three abis, the default in /lib32 while /lib and /lib64 also exist, and it affects amd64 uclibc which is a non-multilib system with everything in /lib. We have to respect LIBDIR else we get into trouble. I didn't test binki's solution, I came up with an independent more adhoc one. I'll test binki's and if it works, then I'd like to see it committed as an -r1 dropped back down to ~arch. Created attachment 349466 [details, diff]
Respect LIBDIR for multilib
Binki's solution is for 1.0.3. This patch addresses 1.0. and only adds three more sed lines which do the real work. I also added some quotes to make the quoting of variables consistent.
(In reply to Anthony Basile from comment #8) > Created attachment 349466 [details, diff] [details, diff] > Respect LIBDIR for multilib > > This patch addresses 1.0. My "4" key is sticking! That's supposed to be 1.0.4. We should rev bump to -r1 and drop to ~arch. Committed ~arch as xorg-cf-files-1.0.4-r1 with ack form binki and chithead in IRC. I tested on regular i686, amd64, amd64/x32, mips64el/o32/n32/n64 and amd64-uclibc and it looks good. Reopen if this is still a problem. Hopefully imake will go away but there are currently 128 ebuilds / 71 packages depending on it. A daunting task. |