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