Comments (15)
I can't think of any.
Well... #325.
from b2.
On the one side it makes sense, msvc compiler and linker doesn't support long path even with windows opt-in long path support feature. But on the other, it's more like a Boost issue. The only Boost library that needs explicit address-model
and architecture
values is Context. I've summited PR that removed need in them boostorg/context#228 and it got merged but then reverted because of b2 bug, fix for which didn't make to Boost repository quickly enough.
from b2.
This is not really a Boost issue. Let's unwrap the issue in full.
As described in #368, ac
module doesn't find OpenSSL libraries. The module finds a library by trying to link to it. In this case linking fails, because it doesn't use the correct flag (-m32
).
In order for b2 to use that flag both address-model=32
and an appropriate architecture=A
properties have to be present in the requested property set. Boost has been overcoming this inconvenience by using special deduced-X
composed features that 1) add X property to the property set if X is missing (and deduction suceeded), and 2) hide the deduced value from target paths. This works for regular targets.
Unfortunately, it doesn't work for ac
targets. This because the targets aren't built when the full dependency graph is constructed and all property sets are fully simplified to their constituting features. They are built as part of constructing the property sets and build graphs. The success of their builds affects the graphs and usage requirements of other targets. So, they are built as part of evaluation of conditional properties.
Conditional properties are evaluated several times, because they can have order of evaluation dependency: property P1 adds property P2 to the property set, property P3 adds P4 to the property set, but only if P2 is in it. So, evaluating P1 then P3 gives P1 P2 P3. But evaluating P3 then P1 gives P1 P2 P3 P4. Due to this effect, ac
targets often have to be built several times for different property sets. In the concrete example of Boost.MySQL, the user requests address-model=32
, the module ac
constructs targets to check if /openssl//ssl
can be linked to with address-model=32
; then, during the second round of evaluation of conditionals, it does the same only with property set address-model=32 deduced-architecture=x86
. The first should fail to build, the second should succeed.
But the second will not in fact be built again. This is because deduced-architecture
is a hidden feature, and does not affect the target path. So, /openssl//ssl/<address-model>32
and /openssl//ssl/<address-model>32,<deduced-architecture>x86
lead to building the same JAM targets , something like <pbin.v2/gcc-12/address-model-32/debug/threading-multi>ssl
. After the first attempt, the build system has determined that that target has failed to build and will not attempt to do it again in the same run.
This is why boostorg/boost#894 removes those hidden features and relies on regular features instead. The issue fundamentally isn't tied to Boost at all.
What are the potential ways to fix the issue, while keeping hidden features? We could change gcc.jam
to add the flag -m32
when there's no architecure
feature in the property set. Effectively, the build system would presume a compatible host. Another way to fix this is making low-level b2 calls to UPDATE_NOW
to ignore whether the updated target has been built or not. Both sound very hacky to me. Hence, the removal of hidden features.
BTW, in theory, this isn't just a problem with ac
targets. Let's say, somehow a regular target is built with 2 property sets: one has <address-model>32
and another has <address-model>32 <deduced-architecture>x86
. We are back to the same problem: the first one to build will determine the success of both. I can't imagine why someone would deliberately do this, so this probably can never happen in correctly written build scripts, but can mainfest in badly written ones.
from b2.
In order for b2 to use that flag both
address-model=32
and an appropriatearchitecture=A
properties have to be present in the requested property set.
I consider that a bug in b2.
But the second will not in fact be built again. This is because
deduced-architecture
is a hidden feature, and does not affect the target path. So,/openssl//ssl/<address-model>32
and/openssl//ssl/<address-model>32,<deduced-architecture>x86
lead to building the same JAM targets , something like<pbin.v2/gcc-12/address-model-32/debug/threading-multi>ssl
. After the first attempt, the build system has determined that that target has failed to build and will not attempt to do it again in the same run.
Hmmm, maybe #303 was a wrong idea, I don't know.
What are the potential ways to fix the issue, while keeping hidden features? We could change
gcc.jam
to add the flag-m32
when there's noarchitecure
feature in the property set.
I have a patch in the stash that does that. I think it makes no sense that address-model
is ignored unless architecture
is set too. From the change history it was not initially, but it was causing issues for other architectures.
from b2.
Philosophically it is not correct to add -m32
unless the target architecture is known to be appropriate. Whether it is practically better is debateable. Consider someone building for their architecture that is not well supported by b2. They put using gcc : : : <compileflags>-m32am : <address-model>32 ;
into their configs. They run the build with b2 address-model=32
, only to see gcc -m32 -m32am
in the logs. Now what do they do?
from b2.
Philosophically it is not correct to add
-m32
unless the target architecture is known to be appropriate. Whether it is practically better is debateable. Consider someone building for their architecture that is not well supported by b2. They putusing gcc : : : <compileflags>-m32am : <address-model>32 ;
into their configs. They run the build withb2 address-model=32
, only to seegcc -m32 -m32am
in the logs. Now what do they do?
That's a straw man. I didn't propose to add -m32
for every architecture, GCC supports it only for a few arches. But it also doesn't care if you put multiple -m
flags (https://godbolt.org/z/7dYz16ExW), the last will win, so your example is fine, I guess.
I honestly consider address-model
a mistake. The only legitimate use-case for it would be x32 abi which doesn't fit into current scheme either, but the ship has sailed.
from b2.
I honestly consider
address-model
a mistake.
What do you mean by that? That 32 bit should be a separate architecture
?
How would that solve our problem?
from b2.
That's a straw man. I didn't propose to add -m32 for every architecture,
Well, then what does this mean?
We could change gcc.jam to add the flag -m32 when there's no architecure feature in the property set.
I have a patch in the stash that does that.
But it also doesn't care if you put multiple
-m
flags
I just tried
gcc -c 1.cpp -maix32 -m32 -o 1.o
And got
gcc: error: unrecognized command-line option ‘-maix32’; did you mean ‘-mavx2’?
So, adding wrong flags only works if GCC has been configured to recognise them. Which is not necessarily the case. So, again, maybe practically things will work, maybe they won't. And fixing it on the user side would probably require patching gcc.jam.
Although, doing something like this should probably work:
feature.extend architecture : myarch ;
toolset.flags gcc.compile OPTIONS <target-os>linux/<architecture>myarch/<address-model>32 : -m32am ;
toolset.flags gcc.link OPTIONS <target-os>linux/<architecture>myarch/<address-model>32 : -m32am ;
But it suddenly requires much more understanding of b2 from the user.
from b2.
#379 Oh, you meant, you wanted to add architecture deduction to toolset modules. I see.
from b2.
Another option is to special-case architecture
and address-model
and instead of adding address-model-64/architecture-x86/
to the path, just add x86-64/
to it.
from b2.
Yet another option is to have a max property set path length threshold in b2.exe and switch to a hash automatically once that is hit.
Unfortunately we'll have to set some arbitrary constant there because the combined path depends on the current directory. But it will be better than nothing.
from b2.
We're looking at implementing the x86_64/
suggestion above on the Boost side, via boostorg/boost#898.
from b2.
IMO.. We should make the hash mode the default on Windows if we truly want to resolve this. Anything else just postpones the problem.
from b2.
Hiding the paths isn't ideal; it's useful to see what's being built. At minimum we should keep the paths that don't exceed the hash length (32), but the budget can also be set a bit higher (e.g. 40).
from b2.
I have an idea that can alleviate the issue and it involves a change that I've wanted to make for a while: feature minimization should consider toolset defaults and requirements (toolset.add-defaults
/toolset.add-requirements
) as default property values.
That will allow msvc toolset to do toolset.add-defaults <toolset>msvc:<architecture>$(host-arch) <toolset>msvc:<address-model>$(host-addrmdl)
which would make property-set.as-path
to not produce the address-model-64/architecture-x86/
part even when they were explicitly set.
But such minimization might open a can of worms: cache could become invalid suddenly, in a way like free
features currently are considered like incidental
for a target uniqueness/path (which is a build cache key, and I think is a serious b2 bug that I might have already exposed users to by #303). While adding such toolset defaults might make users assume that <architecture>
and <address-model>
are always defined and rely on them in their scripts.
from b2.
Related Issues (20)
- b2 fails to build for clang 3.6 HOT 1
- FreeBSD builds in CI HOT 2
- Manifest-related problems with b2 building in msvc-14.0 HOT 2
- Can't compile and install b2 with b2 HOT 1
- How to build clangw .lib HOT 2
- `b2` build fails on gcc 4.8 HOT 1
- b2 can't find MSVC toolset for Visual Studio 2022 v17.9.0 HOT 2
- Warnings about freeing a non-allocated object
- Infinite recursion in `bcp` tests HOT 3
- Config checks using `address-model=32` in Linux don't use the right flags HOT 2
- [question] Best way to pass _GLIBCXX_USE_CXX11_ABI=0/1 using b2?
- lzma.jam doesn't support building from source, like zlib.jam and bzip2.jam HOT 1
- zstd.jam doesn't support building from source, as zlib.jam and bzip2.jam do
- Linking Fails - dangerous relocation: R_AMD64_IMAGEBASE with __ImageBase undefined HOT 2
- Boost build fails when VS 2022 Preview is installed HOT 14
- Generate compile_commands.json HOT 8
- build error-boost1.85 with VS2022 under win10 HOT 1
- after setting using zstd in project-config.jam boost.iostreams still can not detect zstd HOT 2
- Option to turn off wasm-exceptions not available for emscripten builds HOT 2
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from b2.