Re: C++ and read redefinition

[Daniel R. Hurtmans]

Hi,

Thanks Bruno for your clarifications and the tentative workaround.

Actually it didn't fully work. It certainly helped solving the armadillo 
#pragma problem but eventually I got a bunch of undefined references or 
even unresolved functions at link time:

undefined reference to `std::basic_ifstream<char, std::char_traits<char> 
>::_close()'

undefined reference to `std::istream::_read(char*, long long)'


Based on what you mentionned and since I'm 100% C++ (at least I think 
so), I've found that the only workaround was to undefined read, write, 
open and close as soon as I've included unistd.h.
I'm not sure of the impact it will have at the end. I only think of 
socket operations which may be affected (if any).
Anyway I didn't noticed any difference on the systems I'm compiling on.

Daniel


On 04/12/2020 21:18, Bruno Haible wrote:
> 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