Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 30 Aug 2010 19:40:01 +0400
From:      pluknet <pluknet@gmail.com>
To:        Tijl Coosemans <tijl@coosemans.org>
Cc:        freebsd-arch@freebsd.org
Subject:   Re: Support for cc -m32
Message-ID:  <AANLkTi=%2BuG4qEpavQVtrAaCuu1SLQ9--kJGmv9LYCvEm@mail.gmail.com>
In-Reply-To: <201008301731.19074.tijl@coosemans.org>
References:  <201007291718.12687.tijl@coosemans.org> <201008301731.19074.tijl@coosemans.org>

next in thread | previous in thread | raw e-mail | index | archive | help
On 30 August 2010 19:31, Tijl Coosemans <tijl@coosemans.org> wrote:
> On Thursday 29 July 2010 17:18:03 Tijl Coosemans wrote:
>> I've put the initial version of some patches online to support cross
>> compilation of 32 bit binaries on amd64. It's modelled after how NetBSD
>> does this.
>>
>> With these patches something like "cc -m32 -o test test.c -pthread -lm"
>> generates a program that runs on FreeBSD/i386.
>>
>> http://people.freebsd.org/~tijl/cc-m32-1.diff
>> http://people.freebsd.org/~tijl/cc-m32-2.diff
>> http://people.freebsd.org/~tijl/cc-m32-3.diff
>>
>> *cc-m32-1.diff* : Let ld and cc find 32 bit libraries.
>>
>> *cc-m32-2.diff* : Install i386 headers on amd64.
>>
>> With this patch headers for a particular $arch are always installed
>> under /usr/include/$arch and /usr/include/machine becomes a symlink.
>>
>> A question I have here is how best to clean up the old machine
>> directory. The patch currently uses 'rm -rf'.
>>
>> Another problem I encountered was that during the build of
>> usr.bin/kdump all headers are searched for definitions of ioctl
>> requests and a C source code file is generated that includes all those
>> headers. This fails when both i386 and amd64 headers are installed
>> because they can't both be included at the same time. For now the patch
>> simply blacklists /usr/include/i386, but actually all $arch should be
>> excluded. The ioctl requests can still be found through the machine
>> symlink. If someone has a better idea...
>>
>> *cc-m32-3.diff* : Modify amd64 headers to include i386 headers when
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 __i386__ is defined.
>>
>> This patch modifies the amd64 headers to follow this format:
>>
>> =A0 #ifndef _AMD64_HEADER_H
>> =A0 #define _AMD64_HEADER_H
>>
>> =A0 #ifdef __i386__
>> =A0 #include <i386/header.h>
>> =A0 #else
>>
>> =A0 ...
>>
>> =A0 #endif /* __i386__ */
>> =A0 #endif /* !_AMD64_HEADER_H */
>>
>> This way including <machine/header.h> works for -m32. There are a few
>> i386 headers which don't exist for amd64:
>>
>> apm_segments.h
>> bootinfo.h
>> cserial.h
>> elan_mmcr.h
>> if_wl_wavelan.h
>> ioctl_bt848.h
>> ioctl_meteor.h
>> npx.h
>> pcaudioio.h
>> pcb_ext.h
>> perfmon.h
>> privatespace.h
>> smapi.h
>> speaker.h
>> vm86.h
>> xbox.h
>>
>> Theoretically a dummy amd64 header should be created for each of them
>> that just includes the i386 header. The patch does this for npx.h. The
>> other headers seem to be really i386 specific or even outdated. If it
>> were ever necessary to cross-compile code that uses them, it would be
>> easy to modify that code to directly include <i386/header.h>.
>>
>>
>> Feel free to test the patches and to comment on any part of them.
>
> I'd like to move forward with this now. I've rebased the patches above
> against today's CURRENT. If there are no further objections I'd like to
> commit them a few days from now, let's say Saturday.
>

Hi.

The trouble I faced while was playing with my -m32 work
was a cross buildworld error on amd64 with TARGET set to i386.
Have you checked there is no such an issue?

--=20
wbr,
pluknet



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?AANLkTi=%2BuG4qEpavQVtrAaCuu1SLQ9--kJGmv9LYCvEm>