From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 44831 invoked by alias); 7 Mar 2019 16:59:58 -0000 Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org Received: (qmail 44822 invoked by uid 89); 7 Mar 2019 16:59:57 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-1.9 required=5.0 tests=AWL,BAYES_00,KAM_SHORT,SPF_HELO_PASS,SPF_PASS autolearn=ham version=3.3.1 spammy= X-HELO: smtp.polymtl.ca Received: from smtp.polymtl.ca (HELO smtp.polymtl.ca) (132.207.4.11) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Thu, 07 Mar 2019 16:59:56 +0000 Received: from simark.ca (simark.ca [158.69.221.121]) (authenticated bits=0) by smtp.polymtl.ca (8.14.7/8.14.7) with ESMTP id x27GxnXY027894 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for ; Thu, 7 Mar 2019 11:59:54 -0500 Received: by simark.ca (Postfix, from userid 112) id 6C7321E658; Thu, 7 Mar 2019 11:59:49 -0500 (EST) Received: from simark.ca (localhost [127.0.0.1]) by simark.ca (Postfix) with ESMTP id D4AA01E477; Thu, 7 Mar 2019 11:59:47 -0500 (EST) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Date: Thu, 07 Mar 2019 16:59:00 -0000 From: Simon Marchi To: Eli Zaretskii Cc: gdb-patches@sourceware.org Subject: Re: MinGW build failure for GDB 8.2.90 with source-highlight In-Reply-To: <83r2bibvlv.fsf@gnu.org> References: <83r2bibvlv.fsf@gnu.org> Message-ID: X-Sender: simon.marchi@polymtl.ca User-Agent: Roundcube Webmail/1.3.6 X-IsSubscribed: yes X-SW-Source: 2019-03/txt/msg00156.txt.bz2 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 > >::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 > >::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 > >::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 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 ? 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