|
Boost : |
From: Andrey Semashev (andrey.semashev_at_[hidden])
Date: 2021-06-04 09:12:42
On 6/4/21 4:07 AM, Peter Dimov via Boost wrote:
> Andrey Semashev wrote:
>> In the particular case of Boost.WinAPI I want it (Boost.WinAPI) to define all the
>> version macros it defines. This way I ensure that the config check is compiling
>> in the same environment as the library will. I actually include a special header
>> from Boost.Filesystem
>> (platform_config.hpp) to define all platform-specific macros, which indirectly
>> includes Boost.Config and Boost.WinAPI.
>
> While on the subject of Filesystem configure checks, I don't know if it's been
> reported already, but the statx kernel call is causing problems; Filesystem
> operations failing with ENOTSUPP.
ENOSYS, perhaps?
Yes, there were reports.
https://github.com/boostorg/filesystem/issues/172
> You shouldn't be assuming that the machine where the library is built will
> be the same as the one the program will run on. (I think this has come up
> in the context of Docker, where Filesystem is probably built in the host
> environment but the program that uses it runs in Docker and apparently
> the supported kernel calls aren't the same. Or perhaps it's built when the
> Docker image is created, not sure.)
My stance on this is that Boost.Filesystem must be built on a system
with kernel headers matching or older than the systems that will run the
binary. This matches the same requirements for Windows. I don't support
configs with headers newer than runtime kernel.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk