Mail Archives: djgpp/2017/11/26/14:21:16
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 -