Hi, Daniel R. Hurtmans wrote: > I'm using gnulib for quite a long time now to supply missing functions > (eg: get_opt) in some C++ projects. And suddenly everything breaks down. > > Apparently read is redefined to _read when compiling for Windows since > this September. I'm cross compiling with x86_64-w64-mingw32.
Yes, we do this in order to make things build with clang, and drop the use of aliases that Microsoft has declared "deprecated". > In some classes I'm defining read, write or open members. > After digging in the archive I found the solution of including > #include <unistd.h> before my class header. Fine. Yes, including <unistd.h> consistently is the fix. > Now I'm facing another problem... since read is now _read it breaks > pragmas... > > Eg using the excellent Armadillo headers library i got this: > > ... > /usr/x86_64-w64-mingw32/include/armadillo_bits/arma_forward.hpp: In > member function ‘arma::state_type::operator int() const’: > > /usr/x86_64-w64-mingw32/include/armadillo_bits/arma_forward.hpp:289:26: > error: expected ‘read’, ‘write’, ‘update’, ‘capture’, ‘seq_cst’, > ‘acq_rel’, ‘release’, ‘relaxed’ or ‘hint’ clause > 289 | #pragma omp atomic read > ... > > I'm including <armadillo> after <unistd.h>. Oh, indeed the OpenMP specification uses a number of identifiers in #pragma directives, including 'read' and 'write'. Gnulib takes the freedom to redefine functions at the preprocessor level. Either '#define read _read' or '#define read rpl_read', depending on circumstances. If Gnulib did these redefines at the linker level, it would open another can of possible problems. In this case, I think there is only one good solution: In your code, between the #include <unistd.h> and #include <armadillo>. add /* Undefine symbols that can occur within OpenMP pragmas. */ #undef read #undef write > I tried defining GNULIB_NAMESPACE without success. This could be made to be a workaround, but only in C++ mode. Bruno
