Re: [Boost-build] generating headers out of Jamfile

Subject: Re: [Boost-build] generating headers out of Jamfile
From: Oliver Kowalke (oliver.kowalke_at_[hidden])
Date: 2011-01-30 10:02:13

Am 30.01.2011 14:52, schrieb Vladimir Prus:
> Oliver Kowalke wrote:
>
>> Am 30.01.2011 14:08, schrieb Vladimir Prus:
>>> Oliver Kowalke wrote:
>>>
>>>> Am 30.01.2011 13:49, schrieb Vladimir Prus:
>>>>> Oliver Kowalke wrote:
>>>>>
>>>>>> Am 29.01.2011 09:17, schrieb Vladimir Prus:
>>>>>>> Oliver Kowalke wrote:
>>>>>>>
>>>>>>>> Am 29.01.2011 08:59, schrieb Vladimir Prus:
>>>>>>>>> FWIW, I am working on a patch to have those features always set for gcc, and
>>>>>>>>> hopefully for other compilers for which they can be reliably inferred. It's the
>>>>>>>>> top thing on my Boost.Build queue.
>>>>>>>>
>>>>>>>> that are good news - what is your time-frame for this feature?
>>>>>>>
>>>>>>> I think I have the hardest bit done. Should complete in a week or so (on trunk).
>>>>>>
>>>>>> do you consider ABI (sysv, eabi, aapcs, etc.)
>>>>>
>>>>> Not really. Can you actually change abi that a given g++ binary uses?
>>>>>
>>>>>> and Binary-Format
>>>>>> (elf,mach-o, etc.) too?
>>>>>
>>>>> Again, I don't think you can change this, for given architecture/target-os. Am I wrong?
>>>>>
>>>>> - Volodya
>>>>
>>>> you are not wrong but I won't change the abi or binary-format - I'd like
>>>> to use both properties to select the correct assembler code in the Jamfile.
>>>
>>> Should not you then be able to use architecture and target os, for the same purpose?
>>
>> sure target-os and architecture are used for the selection too (I use
>> <architecture>,<instruction-set>,<address-model>,<abi>,<binary-format>).
>>
>> <abi>  and<binary-format>  are required because the target os may support
>> different ABIs (for instance MIPS supports multiple ABIs: o32, n32, n64,
>> o64, eabi)
>
> Is there a gcc option to control this? Can gcc reveal the default abi? If so,
> I am sure an 'abi' feature can be made to have always have a value when you
> have MIPS gcc.

AFAIK the 'default' ABI may vary between the gcc releases.

gcc options for the ABI are:
-mabi=32 (default for 32bit)
-mabi=o64
-mabi=n32
-mabi=64 (default for 64bit)
-mabi=eabi

but I doesn't matter what is the 'default' ABI of gcc (or what compiler 
ever) - important is for which ABI the target-os is compiled (compiling 
an app with a different ABI than the target-os may not always work -> 
depends if ABIs are compatible).
For instance you can create an LINUX System for ABI o32 or n64 (see 
http://www.t2-project.org/).

gcc predefined macro (_MIPS_SIM) for mips:

o32: _MIPS_SIM = _ABIO32
n32: _MIPS_SIM = _ABIN32
n64: _MIPS_SIM = _ABI64

I know it is cumbersome to collect all this stuff for several 
architectures (AMR, X86, MIPS, PowerPC, Sparc)

>> or binary-formats (MAC OS X: elf, mach-o).
>
> Or, I though it's always mach-o.

I'm not familiar with Mac OS X - I thought I've read something elf, 
mach-o together with OS X. maybe my statement is wrong.

> What switch does control this? Again, how
> can gcc report which is the default?

The default depends on the target-os.

maybe this gcc option enables it:
        -bundle    Produce a Mach-o bundle format file.

AFAIK gcc does predefine the macro __ELF__ for elf.

Oliver