Subject: Re: [Boost-build] Problem with mingw flavour
From: Juergen Hunold (juergen.hunold_at_[hidden])
Date: 2008-10-31 04:42:20
Hi Volodya !
On Thursday 30 October 2008 21:28:03 Vladimir Prus wrote:
> JÃ¼rgen has reported that if you have any mingw gcc
> configured in user-config.jam, then when building with any configured
> version of gcc, you start to get 'mingw' in compiler name.
That's the observation
> I would
> also assume that any condition testing for mingw would be evaluated to
Not tested, as I always use <target-os>windows,<toolset>gcc as it seems
clearer to me...
[snip quote about toolset initialisation]
> First time we run into mingw compiler, common.check-init-parameters creates
> a subfeature for toolset=gcc, with a value of mingw. And that values
> becomes default -- so it's applied for all invocations. When non-mingw
> compiler is configured, the condition only involves version, so if mingw
> and native compiler have the same version, we get funny results like two
> commands above.
> I can go about fixing this in various technical ways, but it's probably
> best, first, to figure what behaviour we want. I'd imagine we want a few
> different things
A quick workaround would be nice, so I can test with less hassle, but not
necessary at the moment.
> 1. Be able to select the right compiler, by giving its version and some
> 2. Be able, inside Jamfile, to have conditional logic depending on
> various compiler things.
> 3. Ideally, not explicitly specify, on command line, anything can
> can be auto-detected.
That would be great.
> One example is 'architecture' feature. This is clearly something that
> is fully determined by the gcc binary -- I believe that it's just
> technically impossible to create on gcc binary that would target two
> different architectures at the same time.
This depend on how "architecture" is defined. It is possible to build a linux
gcc targeting both x86 and x86_64. The architecture is then defined by "-m32"
and "-m64" flags. Ah sorry, that would then be "address-model" feature...
But it is extremely unlikely to build a toolchain supporting both windows and
> So, if I somehow select a
> compiler, the architecture feature should be set automatically.
That would be nice.
> Now the question is which features should be the key for compiler
> selection, and which should be deduced from the compiler. Consider:
> using gcc : 4.3.1 ; # native (x86-linux) compiler
> using gcc : 4.3.1 : i586-mingw32msvc-g++ ; # x86-windows compiler
> using gcc : 4.3.1 : arm-none-linux-gnueabi-g++ ; # cross to arm bare metal
> The features involved are possibly:
> I suggest we first deal with the flavour. It seems to me that it basically
> duplicates <target-os> -- we can use <target-os>windows to detect the same,
> and for cygwin compiler we'll have <target-os>cygwin. So, I suggest we drop
> this feature, and use target-os instead.
+1 from me.
> The question of what features form primary key is tricky.
> 1. If compiler is selected based on version alone, and
> target-os/architecture is set from it, it means that we cannot have the
> same version in the example above. We probably would need to have two
> versions -- specified by user, and the 'real version' reported by compiler,
> which can be checked in Jamfiles.
Why ? I can check
for all three cases above. I can even specify the gcc-version in the checks.
Or am I missing something ?
> 2. If we also use target-os and/or architecture in compiler selection, it
> forces the user to specify those properties, which is inconvenient. The
> upcoming configure mechanism will make it required to specif those
> properties only once, but still -- is this OK? Maybe it is, after all when
> cross-compiling auto* projects, one usually uses --target=cpu-none-os. I'd
> imagine that if we can reliably detect architecture of the current machine,
> and the architecture of the compiler, we can use host's architecture as
Well, I think this is good enough. If I accidentially forget target-os=windows
for mingw right now, bjam will happily run with host-os = target-os = linux
and mingw g++ will bail out because it groks on -pthread...
If I have the same gcc for host and cross compiling (did not manage to get to
this point with pre-built mingws ;-)) you can drop the toolset=gcc-4.3.2 and
have to only specify target-os=windows. So this is straight forward.
> I don't know what a really good interface would be. Ideas?
What I'm missing is the "address-model" feature. Right now, we have:
feature.feature address-model : 16 32 64 : propagated optional ;
and also "propageted optional" for "architecture".
It would be great if we could remove the "optional" and set some sensible
defaults. Example for a default setup:
g++ -dumpmachine architecture address-model target-os
x86_64-suse-linux x86 64 linux
i486-linux-gnu x86 32 linux
i586-mingw32msvc x86 32 windows
mingw32 x86 32 windows
x86_64-pc-mingw32 x86 64 windows
i386-mingw32 x86 32 windows
Those are all I can find right now :-))
That would set sensible defaults even for a simple "using gcc ;".
Right now, I don't now the default for "address-model" because there is none
for optional features. This makes it quite hard to specify requirements
depending on "address-model".
Hope this makes my intention clear.
-- * Dipl.-Math. JÃ¼rgen Hunold ! Ingenieurgesellschaft fÃ¼r * voice: ++49 511 262926 57 ! Verkehrs- und Eisenbahnwesen mbH * fax : ++49 511 262926 99 ! Lister StraÃe 15 * juergen.hunold_at_[hidden] ! www.ivembh.de * * GeschÃ¤ftsfÃ¼hrer: ! Sitz des Unternehmens: Hannover * Prof. Dr.-Ing. Thomas Siefer ! Amtsgericht Hannover, HRB 56965 * PD Dr.-Ing. Alfons Radtke !
Boost-Build list run by bdawes at acm.org, david.abrahams at rcn.com, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk