Subject: Re: [boost] [outcome] some problems compiling
From: Niall Douglas (s_sourceforge_at_[hidden])
Date: 2017-05-24 01:23:46
On 23/05/2017 22:46, Andrzej Krzemienski via Boost wrote:
> So, I am trying to run my first test program with Boost.Outcome. The
> library fails to compile with GCC 6.3.0 on MinGW on Windows 7. I have filed
> the issue: https://github.com/ned14/boost.outcome/issues/36
Mingw is not on the list of supported compilers at
I refuse to support Mingw, not worth the waste of my time. I will
unofficially support Mingw-w64. Outcome had been tested on mingw-w64
some time ago, but it had become minor broken since, it's now fixed on
develop branch. Thanks for the bug report.
A far better experience than Mingw is to use the Linux Subsystem for
Windows 10. Full Ubuntu 16.04 LTS environment, but on Windows.
> But also, I can see in file <boost/outcome/outcome_v1.0.hpp>, lines 1267 to
> #ifdef __cplusplus
> typedef struct _IMAGEHLP_LINE64
> unsigned long SizeOfStruct;
> void *Key;
> unsigned long LineNumber;
> wchar_t *FileName;
> unsigned long long int Address;
> } IMAGEHLP_LINE64, *PIMAGEHLP_LINE64;
> 1. Why do you check for __cplusplus? Is it a copy-and-paste of some Windows
It's C source code from an all C sub-sub-library brought into the
partially preprocessed edition. That particular all C sub-sub-library
implements POSIX backtrace() and backtrace_symbols() for Windows.
> 2. This class and subsequent functions are defined in anonymous namespace.
> This means they are redefined and recompiled in each translation unit, and
> remain a per TU definition. Is that intent?
Yes. Because it's a C source file, you would get symbol collision errors
-- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/