On 3/04/2012, at 2:16 AM, Ilya Enkovich wrote:

>> 
>> The point is that one can build a toolchain for i686-linux-gnu that will 
>> support both 32-bit and 64-bit multilibs.  The 32-bit multilib will be used 
>> by default, and compilation for 64-bit user-space can be requested with -m64 
>> option.  Even though Android is not supported for -m64, such a toolchain can 
>> support Android as a additional "-m32 -mandroid" multilib.  I.e., the 
>> toolchain will have three multilibs in total: "-m32" (default), "-m64" and 
>> "-m32 -mandroid".  I386/linux64.h will be picked up for such a toolchain, 
>> even though by default it would compile for 32-bit target.  Does this clear 
>> up things?
>> 
> 
> I think I see your point. And it seems to make all this work I'll also
> have to rename i386/gnu-user.h into i386/gnu-user32.h and create
> i386/gnu-user.h with common definitions to be included by
> gnu-user[32|64].h. Otherwise I wont be able to use some definitions
> (i.e. GNU_USER_TARGET_LINK_SPEC and GNU_USER_TARGET_MATHFILE_SPEC) in
> linux64.h. Right?

It's simpler that you think.  The target headers ($tm_file in config.gcc -- 
gnu-user.h, linux*.h, etc. in this case) are all included into tm.h, which 
serves as proxy to all those headers.  All definitions made in preceding 
headers are available in subsequent headers.  So, given that i386/gnu-user*.h 
precedes i386/linux*.h in config.gcc's $tm_file, you only need to touch 
linux*.h.

Thanks,

--
Maxim Kuvyrkov
CodeSourcery / Mentor Graphics

Reply via email to