Documentation on how to build 32bit applications on amd64?

Yuri yuri at
Fri Aug 13 22:58:02 UTC 2010

On 08/13/2010 14:44, Dan Nelson wrote:
> I think Anonymous is right, and that it's due to the /usr/include headers on
> amd64 not being 32-bit-mode aware.  So you end up with some structure
> members being sized for 64-bit machines instead of 32-bit.  I bet struct
> regex_t on your cross-compiled program is the same size as your native
> 64-bit program, where it should match your 32-bit program instead.  I took
> that "-B /usr/lib32" flag from /usr/src/Makefile.inc1 , where it builds the
> lib32 compat libraries, and it looks like it also temporarily installs a
> full 32-bit include directory and compiles against that with "-iprefix
> ${LIB32TMP}/usr/" .  You may have to install a full 32-bit tree somewhere
> and chroot to it to build, or look more closely at how buildworld compiles
> the lib32 stuff and mimic that, or submit patches to the base include files
> that make them 32 and 64-bit compatible depending on compiler flags.

I think the best way is to modify headers to depend on compiler flags 
(__i386/__amd64). This makes such cross compile seamless for all future 
attempts to cross compile.
The problem I see is that there are currently 83 includes of 
<machine/...> headers from outside the machine/ hierarchy.
cd /usr/include && grep -r "<machine" * | grep include | grep -v ^machine
Looks like all of them should be made conditional on compiler flags like 
#if !defined(__i386)
#include <machine/header.h>
#include </usr/src/sys/i386/include/header.h>
Or rather pointing to some location (if any) where 32 bit headers would 
normally reside on amd64 host.
Do you think this is reasonable?
Should I make a patch, or maybe further discuss on hackers@?


More information about the freebsd-questions mailing list