X-Authentication-Warning: delorie.com: mail set sender to djgpp-bounces using -f X-Recipient: djgpp AT delorie DOT com Subject: Re: Linker error due to multiple symbol definitions when compiling gdb 8.0.1 using gcc720 To: djgpp AT delorie DOT com References: <5A1AD7A5 DOT 7020105 AT gmx DOT de> From: "Andris Pavenis (andris DOT pavenis AT iki DOT fi) [via djgpp AT delorie DOT com]" Message-ID: Date: Sun, 26 Nov 2017 21:21:05 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 In-Reply-To: <5A1AD7A5.7020105@gmx.de> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from Quoted-Printable to 8bit by delorie.com id vAQJL8n9012894 Reply-To: djgpp AT delorie DOT com Errors-To: nobody AT delorie DOT com X-Mailing-List: djgpp AT delorie DOT com X-Unsubscribes-To: listserv AT delorie DOT com Precedence: bulk On 11/26/2017 05:03 PM, Juan Manuel Guerrero (juan DOT guerrero AT gmx DOT de) [via djgpp AT delorie DOT com] wrote: > I am trying to compile gdb-8.0.1.  Very unfortunately it requires to use of > a c++ compiler that provides C++11 support.  I have tried gcc640 and gcc720 > and now I get linker problemes because certain symbols are provided twice. > One time by libstdcxx.a and a second time by gdb's own build-gnulib/import/libgnu.a. > The symbol is frexpl but there may be a lot mores.  This function is neither > provided by libc nor by libm.a.  It seems to be that the gpp port thus > provides some substitution for this function and probably for a lot of > other missing ones.  Now the question arises, why this is not recognized > by the configure script?  If the possibility exists that a compiler extends > the existing headers and libraries, why this is not found by the configure > script?  Is there something wrong with the gpp installation so that > certain paths are not updated and thus not seen later by the configure > script?  Must djgpp.env be adjust to automatically reflect the special > headers provided by the c++ compiler? > > Of course, all this is not really a problem.  The configure script can > always be adjusted to ignore the gnulib version and to use the one > provided by the compiler.  But the configuration error will continue > in other packages that will also need to get theit configure script > adjusted accortdingly. > libstdc++ defines ::frexpl if not defined elsewhere in libstdc++/src/c++98/math_stubs_long_double and uses frexp instead. DJGPP have it and result ::frexpl is included in libstdc++.a See: https://gcc.gnu.org/git/?p=gcc.git;a=blob;f=libstdc%2B%2B-v3/src/c%2B%2B98/math_stubs_long_double.cc;h=327778184fa57fdd4c07144f79e95f2ad5320ec8;hb=refs/heads/trunk for details (trunk version). frexpl is used internally in 2 places inside libstdc++, but is not visible at all in in libstdc++ header files. c++config.h in Linux (gcc-8.0.0-20171126): ... /* Define to 1 if you have the `frexpl' function. */ #define _GLIBCXX_HAVE_FREXPL 1 ... /* Define to 1 if you have the `_frexpl' function. */ /* #undef _GLIBCXX_HAVE__FREXPL */ ... #if defined (_GLIBCXX_HAVE__FREXPL) && ! defined (_GLIBCXX_HAVE_FREXPL) # define _GLIBCXX_HAVE_FREXPL 1 # define frexpl _frexpl #endif c++config.h dfor DJGPP (cross-compiler build, gcc-8.0.0-20171126): /* Define to 1 if you have the `frexpl' function. */ /* #undef _GLIBCXX_HAVE_FREXPL */ ... /* Define to 1 if you have the `_frexpl' function. */ /* #undef _GLIBCXX_HAVE__FREXPL */ ... #if defined (_GLIBCXX_HAVE__FREXPL) && ! defined (_GLIBCXX_HAVE_FREXPL) # define _GLIBCXX_HAVE_FREXPL 1 # define frexpl _frexpl #endif Looks like long living  bug in libstdc++. Should perhaps use internal name like _frexpl if not available from libc. Declaring in header is not sufficient as C compiler will not include C++ headers. gcc-7.2.0 cross-compiler for MINGW (I only checked 64 bit version) have frexpl related defines c++config,h same as Linux one. Perhaps there is no primary or secondary targets that have neither _frexpl() not frexpl() and as result bug have remain unnoticed. It seems unlikely that we get upstream changes for gcc-7 series (probably only for next major version) so following changes could be done for DJGPP port: 1) replace 2 uses of __builtin_frexpl inside libstdc++ with frexpl 2) define macro to replace frexpl with _frexpl Andris