Windows build fixes on a Windows host #1777
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
|
Ignoring that it isn't quite working still, the changes here so far look good to me. The boost 1.87 transition sounds like it's going to be painful. It might be easier to port the p2p layer to QUIC instead, but I guess we can wait and see how the Monero port ends up. (On the linux side, I don't think boost 1.87+ is likely to land in the next Debian stable release and will probably be a few Ubuntu non-LTS releases until it comes in). |
Doy-lee
force-pushed
the
doyle-windows-build-fix
branch
from
1e49913 to
9bce032
Compare
As per docs:
```
--layout=<layout> Determine whether to choose library names and header
locations such that multiple versions of Boost or
multiple compilers can be used on the same system.
-- versioned -- Names of boost binaries include
the Boost version number, name and version of
the compiler and encoded build properties. Boost
headers are installed in a subdirectory of
<HDRDIR> whose name contains the Boost version
number.
-- system -- Binaries names do not include the
Boost version number or the name and version
number of the compiler. Boost headers are
installed directly into <HDRDIR>. This option is
intended for system integrators building
distribution packages.
The default value is 'versioned' on Windows, and
'system' on Unix.
```
A Windows build with a Windows host defaults to 'versioned' which dumps
files into the sysroot currently as 'include/boost-1_86/boost/...' which breaks
the build as our CPP files look for '<boost/...>'.
This was previously only set on cross-compiling builds but it also needs to be set on builds where the host machines is running Windows and using MinGW. Without this no threading library will be generated by the Boost build.
`cmake -E env` fails to execute the `./configure` command proceeding it on MSYS MinGW64. It attempts to execute: ``` cd /C/ox/build/release/static-deps-sources/src/zlib_external && /C/Home/Downloads/msys64/mingw64/bin/cmake.exe -E env CC=C:/Home/Downloads/msys64/mingw64/bin/x86_64-w64-mingw32-gcc.exe "CFLAGS=-O2 -fPIC" ./configure --prefix=C:/ox/build/release/static-deps --static ``` And immediately fails with: ``` inappropriate file type or format ``` Something about the way CMake is forwarding args onwards causes a part one part of the step to fail. You can work around this by chaining `env` on again with no side-effects and then follow it up with the ./configure command.
MSYS now packages boost 1.87 which we don't support due to our dependence on epee and their usage of 'asio::io_service' which was deprecated in 1.87. To allow 1.87 we would need to port in changes from Monero, i.e. see monero-project#9628 which may or may not be considered at some point but certainly not now.
For some reason MacOS targets are failing with the following error
```
In file included from /tmp/drone-WJ2bupWq1Tdvg7M8/drone/src/src/bls/bls_aggregator.cpp:1:
In file included from /tmp/drone-WJ2bupWq1Tdvg7M8/drone/src/src/bls/bls_aggregator.h:3:
In file included from /tmp/drone-WJ2bupWq1Tdvg7M8/drone/src/src/common/formattable.h:3:
In file included from /tmp/drone-WJ2bupWq1Tdvg7M8/drone/src/external/oxen-logging/fmt/include/fmt/core.h:16:
In file included from /Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/include/c++/v1/memory:884:
In file included from /Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/include/c++/v1/__memory/allocate_at_least.h:13:
/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/include/c++/v1/__memory/allocator_traits.h:304:9: error: no matching function for call to 'construct_at'
_VSTD::construct_at(__p, _VSTD::forward<_Args>(__args)...);
^~~~~~~~~~~~~~~~~~~
/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/include/c++/v1/__config:897:17: note: expanded from macro '_VSTD'
^
/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/include/c++/v1/vector:919:21: note: in instantiation of function template specialization 'std::allocator_traits<std::allocator<eth::(anonymous namespace)::agg_log>>::construct<eth::(anonymous namespace)::agg_log, const service_nodes::service_node_address &, std::string, void, void>' requested here
__alloc_traits::construct(this->__alloc(), std::__to_address(__tx.__pos_),
^
/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/include/c++/v1/vector:1678:9: note: in instantiation of function template specialization 'std::vector<eth::(anonymous namespace)::agg_log>::__construct_one_at_end<const service_nodes::service_node_address &, std::string>' requested here
__construct_one_at_end(std::forward<_Args>(__args)...);
^
/tmp/drone-WJ2bupWq1Tdvg7M8/drone/src/src/bls/bls_aggregator.cpp:725:39: note: in instantiation of function template specialization 'std::vector<eth::(anonymous namespace)::agg_log>::emplace_back<const service_nodes::service_node_address &, std::string>' requested here
agg_log_lister->error.emplace_back(
^
/tmp/drone-WJ2bupWq1Tdvg7M8/drone/src/src/bls/bls_aggregator.cpp:887:41: note: in instantiation of function template specialization 'eth::(anonymous namespace)::aggregate_result<eth::bls_rewards_response>::error<fmt::join_view<std::__wrap_iter<std::string *>, std::__wrap_iter<std::string *>>>' requested here
return result_data->error(
^
/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/include/c++/v1/__memory/construct_at.h:39:38: note: candidate template ignored: substitution failure [with _Tp = eth::(anonymous namespace)::agg_log, _Args = <const service_nodes::service_node_address &, std::string>]: no matching constructor for initialization of 'eth::(anonymous namespace)::agg_log'
_LIBCPP_HIDE_FROM_ABI constexpr _Tp* construct_at(_Tp* __location, _Args&&... __args) {
```
I can't make much sense from this, somehow it doesn't want to forward the
arguments onto the implicit constructor for agg_log so I've pulled it out into
individual assignment statements.
Doy-lee
force-pushed
the
doyle-windows-build-fix
branch
from
9bce032 to
7d9de1e
Compare
It errors with
```
/tmp/drone-ikXKouzy6eNTFeeK/drone/src/src/cryptonote_core/service_node_list.cpp:3381:28: note: 'unconf' declared here
auto& [txhash, unconf] = *unconf_it;
^
/tmp/drone-ikXKouzy6eNTFeeK/drone/src/src/cryptonote_core/service_node_list.cpp:3429:51: error: reference to local binding 'unconf' declared in enclosing function 'service_nodes::service_node_list::state_t::update_from_block'
.height = unconf.height_added,
```
So just do the simple thing and manually bind them into references.
Static means the function is not exported into the symbol table. Putting it into the header undoes this by declaring the thing globally across all TUs. Additionally this then raises a warning that the function is unused. This is not needed, drop the prototype from the header and reorder the CPP file to declare it before it's used in the TU.
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.
Each of the changes are documented in each commit as to reasons why. This still does not fix a Windows build on a Windows host for reasons that are still beyond me at this point, but it gets all the way to the linking step instead of crashing and burning much earlier.
On a Windows host, the build fails when trying to create the final executables with the following error excerpts:
The missing symbols are being linked in the linking invocation i.e:
../../static-deps/lib/libboost_serialization.aand anmdump of the object reveals the exact symbols that the linker is looking for in for example, the text section of the static library. I've pulled down the command that the CI machine cross compiles with and executed the exact same command with failures.My assessment of the build situation is some platform specific issue regarding
binutilsis breaking on a Windows machine but doesn't on a Linux machine that is cross-compiling a Windows binary (for example the long file name paths as a platform difference is suspect).I've tried shuffling linking library order around as
ldis sensitive to the order that it's listed on the command line to no success. Potentially something also to do withldon Windows struggling with a lot of linking libraries. I've had one instance where a build actually succeeded and produced a usableoxend.exebut I was unable to reproduce this. In that build there were no changes to the build script it just intermittently worked somehow.Unfortunately I don't have a clue what that is for the time being so I'm shipping all the other fixes I've had to make and leave this in a close-to-working but still broken state.
The build had to be updated to using
StaticBuild.cmakebecause MSYS's package manager now ships Boost 1.87 which is incompatible with the codebase (because of legacy epee networking utils that use a deprecated classio_servicevsio_context). Since MSYS is constantly updating and deprecating packages and they do not provide a reliable way to access older versioned packages, having a constantly moving target will make the Windows build difficult to maintain, so I've locked it down by forcing a static build.