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

- Raw text -