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

Simon Marchi
2019-03-07T16:59:58Z

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]