Re: MinGW build failure for GDB 8.2.90 with source-highlight

[Simon Marchi <simon.marchi@polymtl.ca>]

On 2019-03-07 09:35, Eli Zaretskii wrote:
> I've rebuilt the 8.2.90 pretest today on MinGW with source-highlight,
> and the link step failed with this error message:
> 
>        CXXLD  gdb.exe
> 
> d:/usr/bin/../lib/gcc/mingw32/6.3.0/../../../../mingw32/bin/ld.exe:
> source-cache.o: in function
> `ZNSt13basic_filebufIcSt11char_traitsIcEED4Ev':
>      d:/usr/lib/gcc/mingw32/6.3.0/include/c++/fstream:239: undefined
> reference to `std::basic_filebuf<char, std::char_traits<char>
> >::rpl_close()'
> 
> d:/usr/bin/../lib/gcc/mingw32/6.3.0/../../../../mingw32/bin/ld.exe:
> source-cache.o: in function
> `ZNSt14basic_ifstreamIcSt11char_traitsIcEE8rpl_openEPKcSt13_Ios_Openmode':
>      d:/usr/lib/gcc/mingw32/6.3.0/include/c++/fstream:597: undefined
> reference to `std::basic_filebuf<char, std::char_traits<char>
> >::rpl_open(char const*, std::_Ios_Openmode)'
> 
> d:/usr/bin/../lib/gcc/mingw32/6.3.0/../../../../mingw32/bin/ld.exe:
> source-cache.o: in function
> `ZNSt13basic_filebufIcSt11char_traitsIcEED4Ev':
>      d:/usr/lib/gcc/mingw32/6.3.0/include/c++/fstream:239: undefined
> reference to `std::basic_filebuf<char, std::char_traits<char>
> >::rpl_close()'
>      collect2.exe: error: ld returned 1 exit status
>      Makefile:1888: recipe for target `gdb.exe' failed
>      make[2]: *** [gdb.exe] Error 1
>      make[2]: Leaving directory `/d/usr/eli/utils/gdb-8.2.90/gdb'
>      Makefile:8831: recipe for target `all-gdb' failed
>      make[1]: *** [all-gdb] Error 2
>      make[1]: Leaving directory `/d/usr/eli/utils/gdb-8.2.90'
>      Makefile:856: recipe for target `all' failed
>      make: *** [all] Error 2
> 
> The rpl_open and rpl_close thingies come from Gnulib: in the MinGW
> build it replaces 'open' and 'close' with its versions by using
> #define.  Then when we include <fstream> in source-cache.c, the C++
> compiler barfs.
> 
> Is this a Gnulib bug that I should report to its developers, or is
> this our problem?  Perhaps we should simply #undef these two symbols
> before including <fstream>?

Since there are problems to fix with open on mingw (according to [1]), I 
think it's fine that gnulib provides replacements.  And that problem of 
the macros replacing things we don't want them to replace (such as 
std::basic_filebuf::open has occured a few times in the past.

I don't recall what's the long term solution for this.  We could use 
gnulib's namespace support [2], but the disadvantage is that we would 
need to use gnulib::some_function (assuming we name the namespace 
"gnulib") instead of just some_function to use the "fixed" version.  If 
we use some_function directly, it will use the buggy version on those 
systems where it is buggy.

Undefining the macros seems dangerous too, if you actually use the 
"open" function from the C standard library on a system where it is 
buggy, you want to end up with gnulib's fixed version...

Simon

[1] https://www.gnu.org/software/gnulib/manual/html_node/open.html
[2] 
https://www.gnu.org/software/gnulib/manual/html_node/A-C_002b_002b-namespace-for-gnulib.html