The imake configuration files installed during an emerge of xfree-4.3.0-r3 incorrectly specify the cpu architecture for the system. This means that when imake (or xmkmf) is used to configure a source package for compilation, the define -D__i386__ is used as a flag on the compile. This bug potentially results in an incorrectly compiled executable. Reproducible: Always Steps to Reproduce: 1. Take any imake configured source package - I found this when trying to compile xmcd-3.2 from www.ibiblio.org 2. Follow compile/INSTALL instructions. These are essentially: unpack source, run xmkmf, then do make Makefiles followed by make. 3. Actual Results: gcc calls executed by make define -D__i386__ on the command line. Expected Results: __sparc__ or similar should have been defined instead.
Re-assigning to the xfree team as it's more up their alley.
Hiya bartron, noticed your imake skills on the motif bug, want to help out here?
Sure (somehow missed this one...sorry for the slow response). Although I may have an idea, I'm not able to reproduce this here... Michael, could you run this command (with this exact quoting), xmkmf "-D__dummydef__ -v" -a 2>&1 | tee XMKMF.LOG or, if using (t)csh, xmkmf "-D__dummydef__ -v" -a |& tee XMKMF.LOG in xmcd-3.2's toplevel dir and attach XMKMF.LOG here, please? (Since `/usr/X11R6/lib/X11/config/*' should be the same as was used to build xfree itself, the only other two reasons I can think of is either one of the files there has been overwritten since then, or there's a problem with cpp's configuration/invocation)
Hmmm, something wrong with those arguments on xmkmf since xmkmf just spits out the usage string - usage: /usr/X11R6/bin/xmkmf [-a] [top_of_sources_pathname [current_directory]] then exits.
That doesn't seem right... xfree's xmkmf should pass `-D' switches to imake unaltered. A replacement test would be (run in xmcd's source dir) ( rm -f Makefile && \ imake -v -DUseInstalled -I/usr/X11R6/lib/X11/config && \ make Makefiles && \ make depend ) 2>&1 | tee XMKMF.LOG although this one does not catch the case when thers's some other xmkmf / imake somewhere earlier in $PATH...not very likely but would explain above usage message. What is the output of these commands (may have to emerge gentoolkit to get qpkg) which xmkmf qpkg -f `which xmkmf` qpkg -f /usr/X11R6/bin/xmkmf qpkg -f /usr/X11R6/lib/X11/config/site.def # this all in one line ( cd /usr/X11R6/lib/X11/config ; grep 'define .*i386Architecture' * | grep -v Imake.cf ) ?
Oops, sorry, didn't see the X11R6 part in the usage message at first...just ignore that part.
Ok, I've attached a few script files: XMKMF.LOG is the output from the first chain of commands listed in comment #5. testing_xmkmf.out contains a 'script' record of the commands used to produce XMKMF.LOG. finding_xmkmf.out contatins the 'script' record of the second group of commands in comment #5. (Note, both of the .out files contain control characters from the console colour-coding. These are easier to read if you 'cat' the files rather than use more/less to view them.)
Created attachment 26209 [details] 'script' recording of commands in comment #5
Created attachment 26210 [details] another 'script' recording related to commands in comment #5
Created attachment 26211 [details] LOG file produced from commands in comment #5 (see comment #6 for explaination.
Hm, not really sure as to why this happened, but that's what I thought... xmkmf, imake, and a number of imake config files are from openmotif rather than xfree. Another problem is, `site.def' from openmotif defines `i386Architecture YES' (did this file change recently? It is still dated Feb 15, 2001, but I've never seen this define before and there wasn't any problem building openmotif on arches other than i386 here...). Heinrich: we need a new `openmotif/files/site.def' with this line #define i386Architecture YES deleted (but don't remove the old file yet) and a new ~arch'd release that uses the new `site.def'. Second question is how openmotif's imake managed to leak into /usr/X11R6... ${D}/usr/X11R6/lib/X11/config is deleted using rm -rf, which fails on any kind of error except `ENOENT', bins and man pages are deleted with plain rm and should die on all problems.
fixed in -r5
It's fixed.
