amd64/119771: troubles w/ -m32 executables on both amd64 and i386

[A.Yu.Isupov]

The following reply was made to PR amd64/119771; it has been noted by GNATS.

From: "A.Yu.Isupov" <isupov at moonhe.jinr.ru>
To: bug-followup at freebsd.org
Cc: swhetzel at gmail.com
Subject: Re: amd64/119771: troubles w/ -m32 executables on both amd64
    and i386
Date: Sun, 20 Jan 2008 17:27:49 +0300 (MSK)

 >*From:*	"Scot Hetzel" <swhetzel at gmail.com>
 >*Date:*	Sat, 19 Jan 2008 14:18:43 -0600
 
 >The includes are not the same between amd64 and i386.
 >sys/types.h pulls in machine/endian.h and machine/_types.h. These two
 >includes are different.
 >That is why you would need to build the includes for i386 under amd64.
 >An example of building the includes is in stage 5.1 of buildworld.
 
   Because I already got ready 32-bit libs from 6.2-RELEASE i386
 (/usr/lib32 from amd64 contains code, produces SIGILL under i386,
 as I say above), so I do the same for i386 includes. And with addition
 
 	-nostdinc -I/usr/include32
 
 all reported strangeness are eliminated ! Thank you very very mach !!
 (I don't think about so dramatic effect from incorrect includes...)
 
 >You would need to create a 32-bit build environment similar to how
 >buildworld stage 5.1 build the 32-bit libraries, or install
 >FreeBSD/i386 into its own partition/directory and build it from there.
 
   This method SHOULD work, I understand. (The compiler suite will be used
 also 32-bit from i386, am I right ?) However such environment not so
 suitable for everyday working, namely building binaries with 32-bit
 cernlibs and running ones, and again, again, ...
 
   So receipt for me - to use under amd64 a native gcc with -m32, while
 /usr/lib32 and /usr/include32 are from corresponding i386 release,
 and to link -static binary for eliminating problems with correct dynamic
 linker and libs set (anyway, dynamic Xorg libs, as I seen, contains
 dependency names as absolute paths a la /usr/X11R6/lib/<lib>, so can't be used
 from /usr/X11R6/lib32). Because cernlibs itself are static only, the
 -static linking not so strong restriction...
 
   Thank you again !
 
     Isupov A.