Closed MrM21632 closed 5 years ago
Thanks for letting me know!
I think I've come up with at least a temporary solution. It seems as though there are some header files in the libs/chrono/stopwatches/include/boost/chrono
directory that aren't included in boost/chrono
, and (I'm guessing) are needed at some point during compiling. All I did was add this command right before calling ./bootstrap.sh
in the script:
cp -a libs/chrono/stopwatches/include/boost/chrono/. boost/chrono
to copy those files into boost/chrono
. Now the junction isn't being created, allowing the script to continue uninterrupted.
According to René Rivera, "Those links are supposed to appear only for the git checkout of @Boost_Libraries and are created on demand when headers are reference during the header scanning. Creating those for a release is a bug in the release process."
PS. It's also a bug in 7-zip that it can't deal with junctions ;-)
I'm not actually sure if 7-Zip is at fault, given that my build script deletes the source directory before attempting to zip the destination directory. (I didn't investigate whether reversing the order changed anything.)
Steven Watanabe said: "I think this will fix it, but I haven't tested it: https://github.com/boostorg/release-tools/pull/12"
Fixed by https://github.com/boostorg/chrono/commit/2b1ddde7a6a613e750c866d0800cc0fc44468fee , verified with Boost 1.69.0.
You may already be aware of this, but in case you're not, Boost 1.67.0 creates an NTFS junction when compiling and installing. Specifically, it seems to happen with Boost.Chrono:
It's not too severe of an issue (i.e., it doesn't cause the
b2
process to fail), but it will cause 7-Zip to exit with a warning with how your script is currently set up, which in turn causes the script to exit prematurely:There's not much information about this at the moment, aside from this bug report (I'm not the OP, but the other comment is from me). I don't yet know why this is happening with the latest version of Boost, but not the previous version(s).