See attached failed build log for transfig. The error ``Imakefile.c:34: error: Imake.tmpl: No such file or directory'' is caused because the Makefile generated by xmkmf(1) tells imake to look in /usr/lib/X11/config instead of /usr/lib64/X11/config for files (such as Imake.tmpl). The following lines testify to this (each line is taken out of context from the "${S}"/Makefile generated by xmkmf(1)): LIBDIR = /usr/lib/X11 CONFIGDIR = $(LIBDIR)/config IRULESRC = $(CONFIGDIR) ICONFIGFILES = $(IRULESRC)/Imake.tmpl $(IRULESRC)/X11.tmpl $(IRULESRC)/site.def $(IRULESRC)/$(MACROFILE) $(IRULESRC)/xfree86.cf $(IRULESRC)/xf86.rules $(IRULESRC)/xorgsite.def $(IRULESRC)/host.def $(EXTRA_ICONFIGFILES) The ICONFIGFILES is used by the generate Makefile as arguments for calling imake(1). This causes imake's searchpath to include /usr/lib/X11/config, which doesn't exist on a multilib-nosymlink system: ohnopublishing ~ # ls -lha /usr/lib/X11/config ls: cannot access /usr/lib/X11/config: No such file or directory ohnopublishing ~ # ls -lha /usr/lib64/X11/config/Imake.tmpl -rw-r--r-- 1 root root 54K Oct 30 23:00 /usr/lib64/X11/config/Imake.tmpl Where does this LIBDIR variable come from? Well, it's actually stored into /usr/lib64/X11/config/: ohnopublishing ~ # grep -R -e '\(^\| \)LIBDIR =' /usr/lib64/X11/config /usr/lib64/X11/config/X11.tmpl: LIBDIR = LibDir /* configs for xdm, xinit, etc. */ ohnopublishing ~ # grep -R -e '# *define LibDir ' /usr/lib64/X11/config /usr/lib64/X11/config/Amoeba.cf:#define LibDir $(DESTDIR)/profile/module/x11/lib /usr/lib64/X11/config/X11.tmpl:# define LibDir Concat(ProjectRoot,/lib/X11) /usr/lib64/X11/config/X11.tmpl:# define LibDir /usr/lib/X11 Proposed solution: The ``#define LibDir'' statement should take advantage of LibDirName, which is fixed by the xorg-cf-files ebuild and contains the correct lib* -- even for lib32: ohnopublishing ~ # grep -R -e '# *define LibDirName ' /usr/lib*/X11/config /usr/lib32/X11/config/Imake.tmpl:# define LibDirName lib32 /usr/lib32/X11/config/sun.cf:# define LibDirName Concat3(lib,/,Solaris64bitSubdir) /usr/lib64/X11/config/Imake.tmpl:# define LibDirName lib64 /usr/lib64/X11/config/sun.cf:# define LibDirName Concat3(lib,/,Solaris64bitSubdir) The (to be) attached patches cause the ``#define LibDir'' statement to use LibDirName and fixes the transfig failure attached.
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.
