<address-model> requirements don't seem to work outside the Boost root

[pdimov]

When preparing the minimal repro for https://github.com/bfgroup/b2/issues/107, I noticed that <address-model>64 and <address-model>32 requirements don't seem to work outside the Boost Jamroot. My original openssl configuration was

using openssl : : <include>"C:/vcpkg/installed/x64-windows/include" <search>"C:/vcpkg/installed/x64-windows/lib" : <address-model>64 ;
using openssl : : <include>"C:/vcpkg/installed/x86-windows/include" <search>"C:/vcpkg/installed/x86-windows/lib" : <address-model>32 ;

and it didn't work at all.

[Pixel-Minions]

I am having the same issue, when I run something as simple as this when building boost I am using b2 4.9, also tested with 4.8:

b2 address-model=64 architecture=x86
Performing configuration checks

    - default address-model    : none [1]
    - default architecture     : none [1]

Is there a way around? It is failing my compilation of boost.

[grisumbras]

I just tried experimenting with the original (pdimov's) issue and originally I could not reproduce (I'm on Linux, though).

But maybe the problem is that when you declare two configurations for a lib toolset module that are differentiate by a property (value of <address-model> in this case), you need to add the property to the build request? In other words, when you just invoke b2, <address-model> is not added by default, because it's an optional feature. So, you have to do b2 address-model=64. Given that, maybe we need to make it non-optional and default to the build platform's address model (the same way we derive build platform's OS)?

[Kojoley]

<address-model>64 and <address-model>32 requirements don't seem to work outside the Boost Jamroot.

It's by design (unfortunately?). address-model is optional feature. Boost explicitly sets address-model and architecture here https://github.com/boostorg/boost/blob/23d255a3b2eec6cc2cd74fb716dc5a41d871bf01/Jamroot#L172-L175.

[grisumbras]

Making it optional was simpler to implement. I think, in order to make it non-optional the engine would have to provide a builtin-in rule with build platform's address model value.

[Kojoley]

build platform's address model value.

The value of these features is about target, not about host.

[grisumbras]

There needs to be some default if the feature is non-optional. Using the host's value seems like a reasonable default. So the build system have to deduce that value somehow.

[Kojoley]

Using the host's value seems like a reasonable default.

It is, until it is not.

[grisumbras]

I don't get your point. You need some default for a non-optional feature. The default will be used when build request doesn't contain an explicit request for a particular value of the feature. So command b2 would use the default. If you set the default to something that is not the host's address model, then the command b2 will attempt to cross-compile and most likely would fail, unless your already have some compiler toolset configuration.

[Kojoley]

unless your already have some compiler toolset configuration.

using gcc : : aarch64-linux-gnu-g++ ; and you have your hosts values while using a cross-compiler.

[grisumbras]

I still don't get your point. What would you make the default for address-model feature?

[Kojoley]

Why would I? If you want hosts address-model it is better to add host-address-model, though since the value doen't depend on build request - there is no point in adding a feature for it, just a builtin like [ os.platform ] will work. Target's address-model you can obtain either from user request or deducing it by build probing like boostcpp.jam does.

[grisumbras]

This issue is not about building Boost. It is in fact explicitly about not building Boost. So, not sure why you bring boostcpp.jam into it.

It's by design (unfortunately?). address-model is optional feature.

This phrasing implies that you would prefer if address-model was not an optional feature. So, would you, or did I misunderstand you? If you indeed would prefer address-model to be non-optional, then there should be a default value for it.

[Kojoley]

or did I misunderstand you? If you indeed would prefer address-model to be non-optional

You did. I wish it was that simple and there were a single, known by build system, target architecture, but it's just not how the compiler world works. There is Apple Clang which could in a single invocation call its driver multiple times with different targets, in this case even Boosts workaround breaks and Boost.Context couldn't produce multiarch object from assembler files (that's what I'm actually at fixing right at the moment) because it selects them by overloading on abi/address-model/architecture/binary-format/toolset values. Setting a default value for address-model will simply ban multiple already in work usages.

[pdimov]

So, not sure why you bring boostcpp.jam into it.

It's because the current logic for deducing the architecture and the address model is in boostcpp.jam, as already linked: https://github.com/boostorg/boost/blob/23d255a3b2eec6cc2cd74fb716dc5a41d871bf01/Jamroot#L172-L175. (And https://github.com/boostorg/boost/blob/23d255a3b2eec6cc2cd74fb716dc5a41d871bf01/boostcpp.jam#L607-L671).

[pdimov]

Setting a default value for address-model will simply ban multiple already in work usages.

I don't see why.

As an aside, all of my encounters with optional features have been because of problems they create. This here is because conditionals don't work. The other day it was because you can't use <undefined-sanitizer>off as a requirement to turn off UBSan.

[Kojoley]

Setting a default value for address-model will simply ban multiple already in work usages.

I don't see why.

As an aside, all of my encounters with optional features have been because of problems they create. This here is because conditionals don't work. The other day it was because you can't use <undefined-sanitizer>off as a requirement to turn off UBSan.

I feel you pain, I had the same feeling, but honestly, these usages are usually workarounds. About your example: how about fixing undefined behaviors so there is no need to disable UBSAN :-) Or if it is really a false-positive - disable sanitization in code with attributes?

Just remembered that boostcpp.jam deduces address-model=32 for x32, and while that's not wrong in a sense that the pointer is actually 32bit, but everything else is build on top of an illusion that architecture=x86 address-model=32 is i386. There is address-model=32_64 which blows my mind with its name, and it's almost not used.

[pdimov]

Using the host's value seems like a reasonable default.

It's not. Consider b2 toolset=X,Y where X is 32 bit and Y is 64 bit.

So the build system have to deduce that value somehow.

It already does. The issue here is that the deduction is done by boostcpp.jam and is only applied to the Boost project and its subprojects. So things work when inside Boost and don't otherwise.

I don't believe that there's anything Boost-specific in this logic, and in fact it needs to be maintained in tandem with the feature changes in B2 proper. It should be moved to B2.

[pdimov]

I feel you pain, I had the same feeling, but honestly, these usages are usually workarounds. About your example: how about fixing undefined behaviors so there is no need to disable UBSAN :-) Or if it is really a false-positive - disable sanitization in code with attributes?

Not to go wildly off-topic here; I only mentioned this as an example of how optional features suck (you can't set them to "off"). But yes, it's a false positive of the form "object needs to be of type X but is actually of type X" and only happens on M1 Macs. Yeah, it's a workaround, but 85% of everything is workarounds nowadays, and the build system is the right place for the workaround in this specific case.

Just remembered that boostcpp.jam deduces address-model=32 for x32, and while that's not wrong in a sense that the pointer is actually 32bit, but everything else is build on top of an illusion that architecture=x86 address-model=32 is i386. There is address-model=32_64 which blows my mind with its name, and it's almost not used.

The question here is what, specifically, do we gain by having the deduction logic in boostcpp.jam. (32_64 is an odd model and it's not clear whether it means x32 or Apple combined 32+64. Probably the former.)

[Kojoley]

I feel you pain, I had the same feeling, but honestly, these usages are usually workarounds. About your example: how about fixing undefined behaviors so there is no need to disable UBSAN :-) Or if it is really a false-positive - disable sanitization in code with attributes?

Not to go wildly off-topic here; I only mentioned this as an example of how optional features suck (you can't set them to "off"). But yes, it's a false positive of the form "object needs to be of type X but is actually of type X" and only happens on M1 Macs.

You dynamically cast an object (or catching an exception) and the class has hidden visibility? That's a bug in your code :-)

Probably the former.

Yup.

[pdimov]

You dynamically cast an object (or catching an exception) and the class has hidden visibility? That's a bug in your code :-)

No.

[Kojoley]

You dynamically cast an object (or catching an exception) and the class has hidden visibility? That's a bug in your code :-)

No.

It's really an off-topic, but would you mind sharing a bug report?

[grisumbras]

Using the host's value seems like a reasonable default.

It's not. Consider b2 toolset=X,Y where X is 32 bit and Y is 64 bit.

# user-config.jam
toolset X : ... ;
toolset Y : ... ;
project
  : default-build
    <toolset>X:<address-model>64 
    <toolset>Y:<address-model>32
  ;

But also, it's probably the wrong approach, because toolset name is orthogonal to address-model.

So the build system have to deduce that value somehow.

It already does. The issue here is that the deduction is done by boostcpp.jam and is only applied to the Boost project and its subprojects. So things work when inside Boost and don't otherwise. I don't believe that there's anything Boost-specific in this logic, and in fact it needs to be maintained in tandem with the feature changes in B2 proper. It should be moved to B2.

That deduction is probably not appropriate for all projects (it uses mechanism akin to config tests).

[pdimov]

There's no user-config in my example. X and Y are built-in toolsets.

[pdimov]

That deduction is probably not appropriate for all projects

That's not the question. The question is whether lack of deduction is more appropriate. Which it isn't.

(it uses mechanism akin to config tests).

I know what it uses.

[Pixel-Minions]

It seems in my case the issue was related to an incorrect user configuration. I run b2 with the debugging check flag and found that it was trying to load an old python version based on the configuration file found in my user folder. Once removed, it built properly.

[grisumbras]

I might have a solution: add value native , which will be the default.

[grafikrobot]

I might have a solution: add value native , which will be the default.

How is that different from the current empty default value (which is what having it be optional does)?

[grisumbras]

People would be able to do

using openssl : : <include>"C:/vcpkg/installed/x64-windows/include" <search>"C:/vcpkg/installed/x64-windows/lib" : <address-model>native ;
using openssl : : <include>"C:/vcpkg/installed/x64-windows/include" <search>"C:/vcpkg/installed/x64-windows/lib" : <address-model>64 ;
using openssl : : <include>"C:/vcpkg/installed/x86-windows/include" <search>"C:/vcpkg/installed/x86-windows/lib" : <address-model>32 ;

People would be able to do b2 address-model=native,32

[grisumbras]

Also, consider this. I am currently having in my user-config.jam

using gcc : 12 : i686-w64-mingw32-g++-posix   : : <target-os>windows <address-model>32 <threadapi>pthread ;
using gcc : 12 : x86_64-w64-mingw32-g++-posix : : <target-os>windows <address-model>64 <threadapi>pthread ;

With this configs, I cannot build with b2 target-os=linux threadapi=pthread, because none of the configs match.

If I remove <address-model>64 , then b2 target-os=linux threadapi=pthread address-model=32 match both configs and it results in incorrect command invocation.

If address-model was a non-optional feature with default value native, I could do

using gcc : 12 : i686-w64-mingw32-g++-posix   : : <target-os>windows <address-model>32 <threadapi>pthread ;
using gcc : 12 : x86_64-w64-mingw32-g++-posix : : <target-os>windows <address-model>64 <threadapi>pthread ;
using gcc : 12 : x86_64-w64-mingw32-g++-posix : : <target-os>windows <address-model>native <threadapi>pthread ;

And both b2 target-os=linux threadapi=pthread address-model=32 and b2 target-os=linux threadapi=pthread would work.

[Kojoley]

People would be able to do b2 address-model=native,32

You can do it with b2 address-model=,32 currently (it uses address-model- subdir though).