fix deduction of architecture and address-model #879
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
|
Should be against develop. |
grisumbras
force-pushed
the
fix/platform-deduction
branch
from
be0e2e3
to
49858d5
Compare
|
My understanding of what happened is this: originally conditional properties were evaluated only once, and so the composed features |
|
@anarthal please test whether this change fixes things. |
|
This still fails - now differently: https://drone.cpp.al/boostorg/mysql/647/18/3 |
I don't think this is a problem with address model deduction |
|
Actually, I think predef was not the issue, and this is the problem:
I suspect, you don't have 32bit OpenSSL installed. |
There's a file in build directory (in Boost it's BOOST_ROOT/bin.v2 by default) called config.log. That file contains output of the build commands that |
|
This is not the case, as everything passes if I re enable the explicit architecture feature specification. I implemented the explicit check I'm referring to to make inherently flawed builds like this fail instead of silently succeed ignoring my targets. Does going through the reproduction steps described in bfgroup/b2#368 work? |
|
I'm not in my PC right now, when I have the time I'll try to post the config log here. |
|
This is The problem is again that |
|
This is actually very weird, because I see in the target paths that address-model=32 is being propagated to the check target. So, it should affect the build. I'm inclined to think that the problem isn't with deduction. |
|
address-model=32 is propagated (as it's explicitly specified), but maybe the architecture is not. |
|
I have a similar problem here locally: when I specify in This isn't fixed by this PR; as far as I can see the behavior is the same. |
|
This is the beginning of the b2 output: |
|
This is the abridged config.log output: (more architecture checks elided) |
|
The source of the problem is that module So, given the fact that conditional properties are evaluated one after another, whether you got correct config checks is up to pure random chance. Unless you have a multiconfig build, in which case you are sure to get incorrect config checks. Interestingly, it is only recently that conditional properties started to be evaluated repeatedly, until the property set "stabilizes". Before that they were only evaluated once, and so this random chance thing was unavoidable if you used deduced |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Fix bfgroup/b2#368