Re: building 32bit binaries

["Christoph Egger" <Christoph_Egger%gmx.de@localhost>]

> On Mon, Oct 22, 2007 at 03:38:42PM +0200, Christoph Egger wrote:
> > I discovered another issue related to compiling 32bit binaries.
> > When a .c file
> > 
> > #include <stdint.h>
> > 
> > it always gets the amd64 type definition.
> > gcc -m32 option #define's  __i386__. So it is possible to always get
> > the correct type definition either from /usr/include/i386 
> > or /usr/include/amd64 depending on if gcc is called with -m32 or -m64
> > (-m64 is the default).
> 
> This is not as easy as the linker scripts. The right thing would probably
> be to install the i386 header in addition to the amd64 ones
> (this isn't too difficult) but I've no idea how to make gcc points
> <machine/...> to the right directory based on -m32/-m64.

Usually you include <stdint.h> and not <machine/stdint.h>.
So you can point gcc to <i386/stdint.h> by doing:

#ifdef __i386__
#include <i386/stdint.h>
#endif
#ifdef __x86-64__
#include <machine/stdint.h>
#endif

And in <machine/stdint.h> you should have this:

#ifdef __i386__
#error This header is 64bit only. Use <stdint.h> instead.
#endif

Of course do this also counts analogous for all headers in /usr/include/.

> Then, in order to have gcc -m32 fully working we'd need to build NetBSD
> 32bit binaries as part of the amd64 build.sh.

NetBSD/amd64 can provide extra sets to install:
base32.tgz, comp32.tgz, x11-32.tgz, etc.

> Then there's the issue that 32bit binaries are in /emul/netbsd32, which
> is probably not the place where gcc expect the libraries to be ...

If the 32bit binaries require a shared 32bit libc somewhere, then the
dynamic linker has to find it in order to run the 32bit binaries.
So the "issue" with the dynamic linker is already solved?

ld has a list of default directories where to search through. ld must use
a different default directory list when -melf_i386 is passed to it.

Solaris provides 32bit/64bit headers and libs for many years.
You can look at there for ideas, too.

> To fix this immediate problem, I've just added the 2 missing i386 headers
> in the xentools3-hvm package. It doesn't need the 32bit libraries.

After a cvs update, a ls only shows me these files:

NetBSD.mk
hvm-nbsd
qemu-ifup-nbsd*
xenio.h
xenio3.h

anoncvs.netbsd.org seems to be out-of-date.

-- 
Greetings,

Christoph