Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

fix deduction not properly working #894

Merged
merged 1 commit into from
Apr 30, 2024

Conversation

grisumbras
Copy link
Member

@grisumbras grisumbras commented Apr 29, 2024

This should finally fix bfgroup/b2#368.

Background. After my b2 PR (bfgroup/b2#375) was merged, the build system is properly creating two alternatives for checked libraries (e.g. /openssl//ssl): before the deduced properties are added, and after that. What this does not result in, though, is build system actually compiling and linking corresponding files twice. This is because deduced-X are hidden features, and they do not affect the target path. As a result foo.o with address-model=32 , and foo.o with address-model=32 deduced-architecture=x86 result in the same file (e.g. gcc-13/debug/address-model-32/threading-multi/visibility-hidden/foo.o, notice the lack of architecture).

After some thinking, I decided that this is a flaw in how deduced platform features are implemented. They should not be hidden, because their presence affects binary compatibility.

This change removes deduced-X features, as their only purpose was hiding the related property from the path. Instead it fully relies on conditional property adding the deduced values for X feature if necessary.

NOTE: the unfortunate result of this change is that all targets in a Boost build will get architecture-A and address-model-M parts in the path.

@pdimov
Copy link
Member

pdimov commented Apr 29, 2024

That's probably the right thing to do, but it has the potential of breaking previously working builds on Windows due to path limits.

I'm not sure whether there's anything we can do about that, though.

@pdimov
Copy link
Member

pdimov commented Apr 29, 2024

(References bfgroup/b2#375).

@pdimov pdimov merged commit b96adaa into boostorg:develop Apr 30, 2024
22 checks passed
@grisumbras grisumbras deleted the fix/platform-deduction branch May 1, 2024 06:55
@pdimov
Copy link
Member

pdimov commented May 1, 2024

Yeah, I'm hitting Windows path limits when building with MinGW-w64:

...failed gcc.compile.c++ ..\..\bin.v2\libs\uuid\test\~hdr-decl-detail-basic_name_generator~hpp.test\gcc-8\release\address-model-64\architecture-x86\cxxstd-14-iso\threadapi-win32\threading-multi\visibility-hidden\~hdr-decl-detail-basic_name_generator~hpp.o...
gcc.compile.c++ ..\..\bin.v2\libs\uuid\test\~hdr-decl-detail-basic_name_generator~hpp.test\gcc-8\release\address-model-64\architecture-x86\cxxstd-1z-iso\threadapi-win32\threading-multi\visibility-hidden\~hdr-decl-detail-basic_name_generator~hpp.o
Assembler messages:
Fatal error: can't create ..\..\bin.v2\libs\uuid\test\~hdr-decl-detail-basic_name_generator~hpp.test\gcc-8\release\address-model-64\architecture-x86\cxxstd-1z-iso\threadapi-win32\threading-multi\visibility-hidden\~hdr-decl-detail-basic_name_generator~hpp.o: No such file or directory

If we keep this, bfgroup/b2#378 will be urgently required. Or we need to figure out a way to enable --abbreviate-paths on the Boost side if B2 doesn't cooperate.

@pdimov
Copy link
Member

pdimov commented May 1, 2024

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.

@pdimov
Copy link
Member

pdimov commented May 1, 2024

#898

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants