[boost, config, context, log, 1.58] address-model and architecture detection

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
45 messages Options
123
Reply | Threaded
Open this post in threaded view
|

[boost, config, context, log, 1.58] address-model and architecture detection

Vladimir Prus-3

Hi,

for some time on develop, top-level Jamroot used to deduce address-model and architecture from
compiler. The only issue was that both properties would be added to targets paths when not
necessary. Fix for that has been just committed, for develop:

     https://github.com/boostorg/boost/commit/945e3c0bbdd31ce8c297e0aff5340f0adb196cea

and I performed these operations on master:

- Merged all of Boost.Build changes:

     https://github.com/boostorg/build/commit/2e764707e03d25b6928501c25a717e195c0a8851

- Cherry-picked one Boost.Context change:

     https://github.com/boostorg/context/commit/9b392c68b59021aa4801dcb245bc64ad5c4dd658

- Cherry-picked one Boost.Log change:

     https://github.com/boostorg/log/commit/27a822a6b82f8bf34cbc681ac6583412bdf27d85

- Cherry-picked two root project changes and updated pointers to Context and Log:

     https://github.com/boostorg/boost/commit/e3bc35f7891e72ad74e57dc216db899d162373f5
     https://github.com/boostorg/boost/commit/beb53b6b9574f95309384bfc5afffb40d467bc04
     https://github.com/boostorg/boost/commit/b69a072401695c9978085158af4c1ea84cea33ba

With that, "./b2 -n" in up-to-date checkout of superproject works fine on Linux.
Also, "./b2 -n --with-context --with-system" works fine, no address-model elements in
path. Putting explicit address-model=64 does not change path. Putting explicit
address-model=32 does add this element to path, as expected.

Note that:

- I did not merge any other Boost.Context or Boost.Log changes.
- Nothing was required for Boost.Config, since it was merged earlier.

I'd appreciate if people test current state of master branch, and report any concerns.

Thanks,

--
Vladimir Prus
CodeSourcery / Mentor Embedded
http://vladimirprus.com


_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: [boost, config, context, log, 1.58] address-model and architecture detection

Andrey Semashev-2
On Saturday 04 April 2015 20:57:45 Vladimir Prus wrote:
>
> I'd appreciate if people test current state of master branch, and report any
> concerns.

Thanks Vladimir. Boost.Log tests passed locally.


_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: [boost, config, context, log, 1.58] address-model and architecture detection

Niall Douglas
In reply to this post by Vladimir Prus-3
On 4 Apr 2015 at 20:57, Vladimir Prus wrote:

> for some time on develop, top-level Jamroot used to deduce address-model and architecture from
> compiler. The only issue was that both properties would be added to targets paths when not
> necessary. Fix for that has been just committed, for develop:

Does this mean that on Windows, if building Boost with

b2 stage

... on a x64 machine, we finally default produce 64 bit binaries not
32 bit ones?

If so, I take my hat off to whoever is responsible. Long overdue that
fix.

Niall

--
ned Productions Limited Consulting
http://www.nedproductions.biz/ 
http://ie.linkedin.com/in/nialldouglas/




_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

SMime.p7s (8K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: [boost, config, context, log, 1.58] address-model and architecture detection

Steven Watanabe-4
AMDG

On 04/04/2015 02:00 PM, Niall Douglas wrote:

> On 4 Apr 2015 at 20:57, Vladimir Prus wrote:
>
>> for some time on develop, top-level Jamroot used to deduce address-model and architecture from
>> compiler. The only issue was that both properties would be added to targets paths when not
>> necessary. Fix for that has been just committed, for develop:
>
> Does this mean that on Windows, if building Boost with
>
> b2 stage
>
> ... on a x64 machine, we finally default produce 64 bit binaries not
> 32 bit ones?
>
> If so, I take my hat off to whoever is responsible. Long overdue that
> fix.
>

No, it doesn't.  It will still do whatever the
compiler does by default, which is the right
thing to do anyway.  The change was to make these
properties available for libraries that need
to select different implementations based on
these properties. i.e. choosing x86_64 asm vs
i686 asm in Boost.Context.

In Christ,
Steven Watanabe


_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: [boost, config, context, log, 1.58] address-model and architecture detection

Beman Dawes
In reply to this post by Vladimir Prus-3
On Sat, Apr 4, 2015 at 1:57 PM, Vladimir Prus <[hidden email]>
wrote:

>
> Hi,
>
> ...
>
> I'd appreciate if people test current state of master branch, and report
> any concerns.
>

Without docs or examples as to what should happen, it is hard to know
whether everything is working correctly.

On 64-bit Windows 7, with toolset=gcc, I get:

Performing configuration checks

    - 32-bit                   : no
    - 64-bit                   : yes
    - arm                      : no
    - mips1                    : no
    - power                    : no
    - sparc                    : no
    - x86                      : yes

But with toolset=msvc-12.0, I get:

Performing configuration checks

    - 32-bit                   : yes
    - arm                      : no
    - mips1                    : no
    - power                    : no
    - sparc                    : no
    - x86                      : yes

That seems a bit odd to me.

Other questions:

* Should I be able to build both the 32-bit and 64-bit address models in
the same b2 run?

* If so, what does the command line look like?

* Should auto-linking work?

* If so, how do the names for the library files differ?

* How do we tell a test to run against both 32 and 64-bit builds?

Thanks for working on this!

--Beman

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: [boost, config, context, log, 1.58] address-model and architecture detection

Steven Watanabe-4
AMDG

On 04/04/2015 03:53 PM, Beman Dawes wrote:

> On Sat, Apr 4, 2015 at 1:57 PM, Vladimir Prus <[hidden email]>
> wrote:
>
> Without docs or examples as to what should happen, it is hard to know
> whether everything is working correctly.
>
> On 64-bit Windows 7, with toolset=gcc, I get:
>
> Performing configuration checks
>
>     - 32-bit                   : no
>     - 64-bit                   : yes
>     - arm                      : no
>     - mips1                    : no
>     - power                    : no
>     - sparc                    : no
>     - x86                      : yes
>
> But with toolset=msvc-12.0, I get:
>
> Performing configuration checks
>
>     - 32-bit                   : yes
>     - arm                      : no
>     - mips1                    : no
>     - power                    : no
>     - sparc                    : no
>     - x86                      : yes
>
> That seems a bit odd to me.
>

The configuration output is a bit misleading.
This only indicates that the /default/ architecture
and address-model, now.

> Other questions:
>
> * Should I be able to build both the 32-bit and 64-bit address models in
> the same b2 run?
>

This has never been possible, and is beyond the
scope of Vladimir's changes.  (Note that this
only applies to the top level installation.
Tests have always been able to run with both
32 and 64 bit.)

> * If so, what does the command line look like?
>
> * Should auto-linking work?
>
> * If so, how do the names for the library files differ?
>

They don't, which is the only reason it fails.

> * How do we tell a test to run against both 32 and 64-bit builds?
>

b2 address-model=32,64.

In Christ,
Steven Watanabe


_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: [boost, config, context, log, 1.58] address-model and architecture detection

Steven Watanabe-4
In reply to this post by Beman Dawes
AMDG

On 04/04/2015 03:53 PM, Beman Dawes wrote:

> On Sat, Apr 4, 2015 at 1:57 PM, Vladimir Prus <[hidden email]>
> wrote:
>
>>
>> I'd appreciate if people test current state of master branch, and report
>> any concerns.
>>
>
> Without docs or examples as to what should happen, it is hard to know
> whether everything is working correctly.
>

Everything that worked before this update should
continue to work with unchanged behavior.

In addition, all of the following should work:

b2 [options]
b2 [options] architecture=X
b2 [options] address-model=Y
b2 [options] architecture=X address-model=Y

If either architecture or address-model is
unspecified, then the behavior will be the
same as if it were set to the compiler default.
(For msvc, this is specified as x86/32).

"Works" means that the libraries are built for
the correct architecture, although there's no
easy way to verify this automatically.  The
best way I can think of is to write a trivial
program to link against the newly generated
libraries. file might also work.

If architecture and address-model are not
specified, they should not appear in any
build paths.

In Christ,
Steven Watanabe


_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: [boost, config, context, log, 1.58] address-model and architecture detection

Edward Diener-3
In reply to this post by Vladimir Prus-3
On 4/4/2015 1:57 PM, Vladimir Prus wrote:
>
> Hi,
>
> for some time on develop, top-level Jamroot used to deduce address-model
> and architecture from
> compiler.

Could we get some indication in the Boost Build docs what 'architecture'
values are possible ? The only thing I see there is:

"architecture

     The architecture features specifies the general processor familty
to generate code for."

Did I miss something ?

> The only issue was that both properties would be added to
> targets paths when not
> necessary. Fix for that has been just committed, for develop:
>
>
> https://github.com/boostorg/boost/commit/945e3c0bbdd31ce8c297e0aff5340f0adb196cea
>
>
> and I performed these operations on master:
>
> - Merged all of Boost.Build changes:
>
>
> https://github.com/boostorg/build/commit/2e764707e03d25b6928501c25a717e195c0a8851
>
>
> - Cherry-picked one Boost.Context change:
>
>
> https://github.com/boostorg/context/commit/9b392c68b59021aa4801dcb245bc64ad5c4dd658
>
>
> - Cherry-picked one Boost.Log change:
>
>
> https://github.com/boostorg/log/commit/27a822a6b82f8bf34cbc681ac6583412bdf27d85
>
>
> - Cherry-picked two root project changes and updated pointers to Context
> and Log:
>
>
> https://github.com/boostorg/boost/commit/e3bc35f7891e72ad74e57dc216db899d162373f5
>
>
> https://github.com/boostorg/boost/commit/beb53b6b9574f95309384bfc5afffb40d467bc04
>
>
> https://github.com/boostorg/boost/commit/b69a072401695c9978085158af4c1ea84cea33ba
>
>
> With that, "./b2 -n" in up-to-date checkout of superproject works fine
> on Linux.
> Also, "./b2 -n --with-context --with-system" works fine, no
> address-model elements in
> path. Putting explicit address-model=64 does not change path. Putting
> explicit
> address-model=32 does add this element to path, as expected.
>
> Note that:
>
> - I did not merge any other Boost.Context or Boost.Log changes.
> - Nothing was required for Boost.Config, since it was merged earlier.
>
> I'd appreciate if people test current state of master branch, and report
> any concerns.



_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: [boost, config, context, log, 1.58] address-model and architecture detection

Steven Watanabe-4
AMDG

On 04/04/2015 04:50 PM, Edward Diener wrote:

>
> Could we get some indication in the Boost Build docs what 'architecture'
> values are possible ? The only thing I see there is:
>
> "architecture
>
>     The architecture features specifies the general processor familty to
> generate code for."
>
> Did I miss something ?
>

Fixed in develop.

In Christ,
Steven Watanabe


_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: [boost, config, context, log, 1.58] address-model and architecture detection

Vladimir Prus-3
In reply to this post by Steven Watanabe-4
On 04/05/2015 01:33 AM, Steven Watanabe wrote:

> "Works" means that the libraries are built for
> the correct architecture, although there's no
> easy way to verify this automatically.  The
> best way I can think of is to write a trivial
> program to link against the newly generated
> libraries. file might also work.

With gcc, I just use "-n" to observe command-lines, which contain either -m32 or -m64.

--
Vladimir Prus
CodeSourcery / Mentor Embedded
http://vladimirprus.com


_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: [boost, config, context, log, 1.58] address-model and architecture detection

pabristow
In reply to this post by Beman Dawes


> -----Original Message-----
> From: Boost [mailto:[hidden email]] On Behalf Of Beman Dawes
> Sent: 04 April 2015 22:54
> To: Boost Developers List
> Subject: Re: [boost] [boost, config, context, log, 1.58] address-model and architecture detection
>
> On Sat, Apr 4, 2015 at 1:57 PM, Vladimir Prus <[hidden email]>
> wrote:
>
> >
> > Hi,
> >
> > I'd appreciate if people test current state of master branch, and
> > report any concerns.
 

> Other questions:
>
> * Should I be able to build both the 32-bit and 64-bit address models in the same b2 run?
>
> * If so, what does the command line look like?
>
> * Should auto-linking work?
>
> * If so, how do the names for the library files differ?
>
> * How do we tell a test to run against both 32 and 64-bit builds?
>
> Thanks for working on this!

+1

Would it be easy to also echo the actual command line into the log file?

This would help refreshing ones memory of what one did last time.

Thanks

Paul

PS Is it time to allow 32 and 64 linker file names to be different?

Or else can you suggest how to manage testing in 32 and 64 builds.



_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: [boost, config, context, log, 1.58] address-model and architecture detection

Robert Ramey
In reply to this post by Steven Watanabe-4
Steven Watanabe-4 wrote
If architecture and address-model are not
specified, they should not appear in any
build paths.
This is very confusing.  This means that I often have multiple sets of results which are actually exactly the same. so if I specify

b2 ...

and

b2 addressmodel=64,32

I end up with three sets of results - two of which are identical.  Now I can't tell which the "blank" one is supposed to match.  Please think about this.

Robert Ramey
Reply | Threaded
Open this post in threaded view
|

Re: [boost, config, context, log, 1.58] address-model and architecture detection

Steven Watanabe-4
AMDG

On 04/05/2015 11:41 AM, Robert Ramey wrote:

> Steven Watanabe-4 wrote
>> If architecture and address-model are not
>> specified, they should not appear in any
>> build paths.
>
> This is very confusing.  This means that I often have multiple sets of
> results which are actually exactly the same. so if I specify
>
> b2 ...
>
> and
>
> b2 addressmodel=64,32
>
> I end up with three sets of results - two of which are identical.  Now I
> can't tell which the "blank" one is supposed to match.  Please think about
> this.
>

No, you end up with two sets of results.

Steven Watanabe wrote:
> If either architecture or address-model is
> unspecified, then the behavior will be the
> same as if it were set to the compiler default.

This includes the build directories.

In Christ,
Steven Watanabe


_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: [boost, config, context, log, 1.58] address-model and architecture detection

Robert Ramey
Steven Watanabe-4 wrote
No, you end up with two sets of results.
Hmmmm - That's not what I'm seeing.  I'm seeing a directory with a set of results.  Within that directory I'm seeing a subdirectory named address-model-64 and another one with name address-model-32.  Each of these latter two have their own set of results.  One of these is the same as those in the parent directory.  

In fairness, I'm speaking from memory as I'm now building/testing all combinations.  I'll double check this again when I'm done.

Robert Ramey
Reply | Threaded
Open this post in threaded view
|

Re: [boost, config, context, log, 1.58] address-model and architecture detection

Steven Watanabe-4
AMDG

On 04/05/2015 01:11 PM, Robert Ramey wrote:
> Steven Watanabe-4 wrote
>> No, you end up with two sets of results.
>
> Hmmmm - That's not what I'm seeing.

If so, it's a bug.

>  I'm seeing a directory with a set of
> results.  Within that directory I'm seeing a subdirectory named
> address-model-64 and another one with name address-model-32.  Each of these
> latter two have their own set of results.  One of these is the same as those
> in the parent directory.  
>
> In fairness, I'm speaking from memory as I'm now building/testing all
> combinations.  I'll double check this again when I'm done.
>

Did you clean the old directories?  The code
used to generate both address-model-32 and
address-model-64.  The whole point of Vladimir's
changes was to suppress this directory when it
matches the default compiler settings.

In Christ,
Steven Watanabe


_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: [boost, config, context, log, 1.58] address-model and architecture detection

Robert Ramey
OK - I haven't recently updated and rebuilt b2.  i hadn't realized that recent changes altered this behavior.

Robert Ramey
Reply | Threaded
Open this post in threaded view
|

Re: [boost, config, context, log, 1.58] address-model and architecture detection

Steven Watanabe-4
AMDG

On 04/05/2015 02:39 PM, Robert Ramey wrote:
> OK - I haven't recently updated and rebuilt b2.  i hadn't realized that
> recent changes altered this behavior.
>

 There are no changes to the b2 executable, so
you don't need to rebuild it, but you do need
to update the build repository and the the
superproject.

In Christ,
Steven Watanabe


_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: [boost, config, context, log, 1.58] address-model and architecture detection

Gavin Lambert
In reply to this post by Niall Douglas
On 5/04/2015 08:00, Niall Douglas wrote:

> On 4 Apr 2015 at 20:57, Vladimir Prus wrote:
>
>> for some time on develop, top-level Jamroot used to deduce address-model and architecture from
>> compiler. The only issue was that both properties would be added to targets paths when not
>> necessary. Fix for that has been just committed, for develop:
>
> Does this mean that on Windows, if building Boost with
>
> b2 stage
>
> ... on a x64 machine, we finally default produce 64 bit binaries not
> 32 bit ones?
>
> If so, I take my hat off to whoever is responsible. Long overdue that
> fix.

Building 64-bit on Windows is not the preferred option for the vast
majority of applications, for compatibility reasons.

Typically only those that actually need gobs of memory (read: >1.5GB per
app) get compiled for 64-bit.  While these certainly exist, they're
relatively rare (except in certain domains, perhaps).

So if Boost defaults to building 32-bit on Windows (even 64-bit
Windows), that will make most end users happy and is not a bug.


Although I'll add my +1 to being *able* to build both 32-bit and 64-bit
in the same path, which as noted elsewhere in this thread is not
currently supported.



_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: [boost, config, context, log, 1.58] address-model and architecture detection

Andrey Semashev-2
On Tue, Apr 7, 2015 at 8:58 AM, Gavin Lambert <[hidden email]> wrote:

> On 5/04/2015 08:00, Niall Douglas wrote:
>>
>> On 4 Apr 2015 at 20:57, Vladimir Prus wrote:
>>
>>> for some time on develop, top-level Jamroot used to deduce address-model
>>> and architecture from
>>> compiler. The only issue was that both properties would be added to
>>> targets paths when not
>>> necessary. Fix for that has been just committed, for develop:
>>
>>
>> Does this mean that on Windows, if building Boost with
>>
>> b2 stage
>>
>> ... on a x64 machine, we finally default produce 64 bit binaries not
>> 32 bit ones?
>>
>> If so, I take my hat off to whoever is responsible. Long overdue that
>> fix.
>
>
> Building 64-bit on Windows is not the preferred option for the vast majority
> of applications, for compatibility reasons.
>
> Typically only those that actually need gobs of memory (read: >1.5GB per
> app) get compiled for 64-bit.  While these certainly exist, they're
> relatively rare (except in certain domains, perhaps).

Larger address space is not the only benefit of 64-bit x86. More
registers (GPRs are also widened to 64 bits), mandatory SSE2, new
addressing mode - all these features are very much useful even if you
don't need large amounts of memory. In fact, there is no point in
building 32-bit binaries nowdays, unless you desperately need
compatibility with 32-bit only systems (read - more than a decade
old).

BTW, I think 32-bit Windows spread is overestimated. Here are some
stats from Steam, for example (click "OS Version" in the table):

http://store.steampowered.com/hwsurvey/

Regarding MSVC defaults - I think there is a little misunderstanding
here. There is no "default" from the compiler standpoint, it's just a
matter of environment setup, which defines the compiler executable
(cl.exe) that gets picked. The "default" (i.e. clean) environment is
not suitable for running any cl.exe, b2 has to pick one anyway and run
the corresponding environment setup scripts. It is totally our
decision which one we pick.

So my vote is for building 64-bit binaries on a 64-bit system by
default. This is also consistent with other systems.

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: [boost, config, context, log, 1.58] address-model and architecture detection

Klaim - Joël Lamotte
On Tue, Apr 7, 2015 at 8:38 AM, Andrey Semashev <[hidden email]>
wrote:

> So my vote is for building 64-bit binaries on a 64-bit system by
> default. This is also consistent with other systems.
>

Even with that, having no way for tools (like CMake) to identify one
version from the other
is problematic when you actually need to support both.
Both building the OS native binaries and having a convention to identify
both 32 and 64bit versions would help.

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
123