Boost 1.67.0 Creates NTFS Junction During Install Process

[MrM21632]

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:

mklink-or-dir boost\chrono\stopwatches
Junction created for boost\chrono\stopwatches <<===>> libs\chrono\stopwatches\include\boost\chrono\stopwatches
link.hardlink boost\chrono\stopwatches.hpp
Hardlink created for boost\chrono\stopwatches.hpp <<===>> libs\chrono\stopwatches\include\boost\chrono\stopwatches.hpp

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:

Scan WARNINGS for files and folders:

include\boost\chrono\stopwatches\ : The system cannot find the path specified.
----------------
Scan WARNINGS: 1

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).

[StephanTLavavej]

Thanks for letting me know!

[MrM21632]

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.

[StephanTLavavej]

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."

[grafikrobot]

PS. It's also a bug in 7-zip that it can't deal with junctions ;-)

[StephanTLavavej]

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.)

[StephanTLavavej]

Steven Watanabe said: "I think this will fix it, but I haven't tested it: boostorg/release-tools#12"

[StephanTLavavej]

Fixed by boostorg/chrono@2b1ddde , verified with Boost 1.69.0.