ftp.delorie.com/archives/browse.cgi | search |
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]" <djgpp AT delorie DOT com> |
Message-ID: | <e8eaa1c7-6af3-17a9-9af6-d8d864fe4c3b@iki.fi> |
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> |
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 |
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
webmaster | delorie software privacy |
Copyright © 2019 by DJ Delorie | Updated Jul 2019 |