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
this:
...
#if !defined(__i386)
#include <machine/header.h>
#else
#include </usr/src/sys/i386/include/header.h>
#endif
...
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 hack...@?
Yuri
_______________________________________________
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org"
