FYI. Excluding the c++ part shows that acoshl() and friends are never defined.
> $ cat mtest.c
> #include <math.h>
>
> long double x(long double a) { return acoshl(a); }
From the newlib math.h:
> /* Newlib doesn't fully support long double math functions so far.
> On platforms where long double equals double the long double functions
> simply call the double functions. On Cygwin the long double functions
> are implemented independently from newlib to be able to use optimized
> assembler functions despite using the Microsoft x86_64 ABI. */
> #if defined (_LDBL_EQ_DBL) || defined (__CYGWIN__)
Looking to the GCC cmath header I find.
> #if __cplusplus >= 201103L
>
> #ifdef _GLIBCXX_USE_C99_MATH_TR1
And indeed adding -std=c++98 seems to be a workaround.
The other macro is defined in a target specific header,
which explains why -mcpu= has an effect.
> grep _GLIBCXX_USE_C99_MATH_TR1
> .../lib/gcc/m68k-rtems5/7.5.0/include/c++/m68k-rtems5/*/bits/c++config.h
> .../lib/gcc/m68k-rtems5/7.5.0/include/c++/m68k-rtems5/m5206/bits/c++config.h:#define
> _GLIBCXX_USE_C99_MATH_TR1 1
> .../lib/gcc/m68k-rtems5/7.5.0/include/c++/m68k-rtems5/m5208/bits/c++config.h:#define
> _GLIBCXX_USE_C99_MATH_TR1 1
> .../lib/gcc/m68k-rtems5/7.5.0/include/c++/m68k-rtems5/m5307/bits/c++config.h:#define
> _GLIBCXX_USE_C99_MATH_TR1 1
> .../lib/gcc/m68k-rtems5/7.5.0/include/c++/m68k-rtems5/m5329/bits/c++config.h:#define
> _GLIBCXX_USE_C99_MATH_TR1 1
> .../lib/gcc/m68k-rtems5/7.5.0/include/c++/m68k-rtems5/m5407/bits/c++config.h:#define
> _GLIBCXX_USE_C99_MATH_TR1 1
> .../lib/gcc/m68k-rtems5/7.5.0/include/c++/m68k-rtems5/m5475/bits/c++config.h:#define
> _GLIBCXX_USE_C99_MATH_TR1 1
> .../lib/gcc/m68k-rtems5/7.5.0/include/c++/m68k-rtems5/m68000/bits/c++config.h:/*
> #undef _GLIBCXX_USE_C99_MATH_TR1 */
> .../lib/gcc/m68k-rtems5/7.5.0/include/c++/m68k-rtems5/m68040/bits/c++config.h:/*
> #undef _GLIBCXX_USE_C99_MATH_TR1 */
> .../lib/gcc/m68k-rtems5/7.5.0/include/c++/m68k-rtems5/m68060/bits/c++config.h:/*
> #undef _GLIBCXX_USE_C99_MATH_TR1 */
> .../lib/gcc/m68k-rtems5/7.5.0/include/c++/m68k-rtems5/mcpu32/bits/c++config.h:/*
> #undef _GLIBCXX_USE_C99_MATH_TR1 */
> .../lib/gcc/m68k-rtems5/7.5.0/include/c++/m68k-rtems5/softfp/bits/c++config.h:/*
> #undef _GLIBCXX_USE_C99_MATH_TR1 */
These lines are preceded by:
> /* Define if C99 functions or macros in <math.h> should be imported in
> <tr1/cmath> in namespace std::tr1. */
I hope this gives someone else a hint.
On 2/16/21 4:18 PM, Joel Sherrill wrote:
>
>
> On Tue, Feb 16, 2021 at 5:50 PM Johnson, Andrew N. <a...@anl.gov
> <mailto:a...@anl.gov>> wrote:
>
> On Feb 16, 2021, at 5:26 PM, Joel Sherrill <j...@rtems.org
> <mailto:j...@rtems.org>> wrote:
>>
>> Can you provide a cutdown?
>
> Sure, it’s 1 line of source:
>
>> *tux% *cat m.cpp
>> #include <cmath>
>
>
> I can confirm this one-liner compilers on every rtems 5 and 6 gcc target
> including m68k but when you add mcpu=5282 to either the rtems 5 or 6 gcc it
> does not compile.
>
> The next step would be to look at the multilib directories selected by that.
> Something must be different about that vs the default (m68020 w/FPU).
>
> Luckily I had 4.11 tools laying around and I can report it works with the
> 4.11 GCC. Bad news, is that it is gcc 4.9.3 versus gcc 7. I suspect an
> examination of what that compiler did versus the new one will highlight the
> issue. Then we have to look at the config/m68k/t-* files RTEMS uses for
> changes.
>
> [joel@devel cmath]$
> /home/joel/rtems-cron-411/tools/4.11/bin//m68k-rtems4.11-gcc -c -mcpu=5282
> m.cc
> [joel@devel cmath]$
> /home/joel/rtems-cron-411/tools/4.11/bin//m68k-rtems4.11-gcc --version
> m68k-rtems4.11-gcc (GCC) 4.9.3 20150626 (RTEMS 4.11, RSB
> 158ad680aed1c4fd00f00d5b0e269391597872ef, Newlib 2.2.0.20150423)
>
> I'm afraid I did the quick part since I had the tools. Gedare.. can you do
> some version comparison and gcc git archeology? Just chat me and we can run
> this down.
>
> --joel
>
>
>
>
> which when compiled:
>
>> *tux% */local/anj/RTEMS-5.1/rtems-5.1/bin/m68k-rtems5-g++
>> -B/local/anj/RTEMS-5.1/rtems-5.1/m68k-rtems5/uC5282/lib/ -specs bsp_specs
>> -qrtems -mcpu=5282 -Wall -c m.cpp
>> In file included from *m.cpp:1:0*:
>>
>> */local/anj/RTEMS-5.1/rtems-5.1/lib/gcc/m68k-rtems5/7.5.0/include/c++/cmath:1086:11:*
>> *error: *'*::acoshl*' has not been declared
>> using ::*acoshl*;
>> *^~~~~~*
>>
>> */local/anj/RTEMS-5.1/rtems-5.1/lib/gcc/m68k-rtems5/7.5.0/include/c++/cmath:1090:11:*
>> *error: *'*::asinhl*' has not been declared
>> using ::*asinhl*;
>> *^~~~~~*
> *
> *
> Long list of errors truncated as before.
>
>> And any idea what those using statements are referring to? I know the
>> methods in libm but so not understand what it means in the context of using
>
> I think that's how you ask C++ to import symbols into the current
> namespace (they are all inside a namespace std {...} block), but I’m not a
> C++ expert. In any case they come from gcc. EPICS probably doesn’t need any
> of the missing functions which look to have been added by C99, but we do need
> to be able to pull in math.h and/or cmath from C++ code.
>
> - Andrew
>
>
>> On Tue, Feb 16, 2021, 4:42 PM Gedare Bloom <ged...@rtems.org
>> <mailto:ged...@rtems.org>> wrote:
>>
>> Hi Andrew,
>>
>> On Tue, Feb 16, 2021 at 1:16 PM Johnson, Andrew N. <a...@anl.gov
>> <mailto:a...@anl.gov>> wrote:
>> >
>> > I tried to build the in-progress port of EPICS for the uC5282 BSP
>> last night against a release build of RTEMS-5.1 with tools and BSP built
>> using RSB. It looks like the g++ cmath routines haven't been configured
>> properly for this target. It failed at the first C++ source file includes
>> math.h (other BSPs such as the beatnik and qoriq_e500 get further than this,
>> and only the pc686 build completely succeeds right now):
>> >
>> > > /local/anj/RTEMS-5.1/rtems-5.1/bin/m68k-rtems5-g++
>> -B/local/anj/RTEMS-5.1/rtems-5.1/m68k-rtems5/uC5282/lib/ -specs bsp_specs
>> -qrtems -mcpu=5282 -D_GNU_SOURCE -D_DEFAULT_SOURCE
>> -DUNIX -O2 -g -ffunction-sections -fdata-sections -Wall
>> -DMY_DO_BOOTP=NULL -D__LINUX_ERRNO_EXTENSIONS__ -DHAVE_SOCKADDR_SA_LEN=1
>> -I. -I../O.Common -I. -I../osi/compiler/gcc -I../osi/compiler/default -I.
>> -I../osi/os/RTEMS-posix -I../osi/os/RTEMS -I../osi/os/posix
>> -I../osi/os/default -I.. -I../as -I../bucketLib -I../calc -I../cvtFast
>> -I../cppStd -I../cxxTemplates -I../dbmf -I../ellLib -I../env -I../error
>> -I../fdmgr -I../flex -I../freeList -I../gpHash -I../iocsh -I../log
>> -I../macLib -I../misc -I../osi -I../pool -I../ring -I../taskwd -I../timer
>> -I../yacc -I../yacc -I../yajl -I../../../../include/compiler/gcc
>> -I../../../../include/os/RTEMS -I../../../../include -c
>> ../cxxTemplates/resourceLib.cpp
>>
>> I don't see -lm not sure if that is an issue or not, but it seems
>> suspect. can you snip out the compiler command line to compare with
>> the pc686 build?
>>
>> > > In file included from
>> /local/anj/RTEMS-5.1/rtems-5.1/lib/gcc/m68k-rtems5/7.5.0/include/c++/math.h:36:0,
>> > > from ../cxxTemplates/resourceLib.h:38,
>> > > from ../cxxTemplates/resourceLib.cpp:15:
>> > >
>> /local/anj/RTEMS-5.1/rtems-5.1/lib/gcc/m68k-rtems5/7.5.0/include/c++/cmath:1086:11:
>> error: '::acoshl' has not been declared
>> > > using ::acoshl;
>> > > ^~~~~~
>> > >
>> /local/anj/RTEMS-5.1/rtems-5.1/lib/gcc/m68k-rtems5/7.5.0/include/c++/cmath:1090:11:
>> error: '::asinhl' has not been declared
>> > > using ::asinhl;
>> > > ^~~~~~
>> > >
>> /local/anj/RTEMS-5.1/rtems-5.1/lib/gcc/m68k-rtems5/7.5.0/include/c++/cmath:1094:11:
>> error: '::atanhl' has not been declared
>> > > using ::atanhl;
>> > > ^~~~~~
>> > >
>> > > ... many similar errors snipped ...
>> > >
>> > >
>> /local/anj/RTEMS-5.1/rtems-5.1/lib/gcc/m68k-rtems5/7.5.0/include/c++/cmath:1220:11:
>> error: '::tgammal' has not been declared
>> > > using ::tgammal;
>> > > ^~~~~~~
>> > >
>> /local/anj/RTEMS-5.1/rtems-5.1/lib/gcc/m68k-rtems5/7.5.0/include/c++/cmath:1224:11:
>> error: '::truncl' has not been declared
>> > > using ::truncl;
>> > > ^~~~~~
>> >
>> > There could very well have been errors building the BSP on my part
>> as I had to hand-create a uC5282.bset file for RSB to build it:
>> >
>> > > tux% cat config/5/bsps/uC5282.bset
>> > > %define mail_single_report 1
>> > >
>> > > %define with_rtems_bsp uC5282
>> > > %define rtems_target m68k-rtems5
>> > > %define rtems_host %{rtems_target}
>> > >
>> > > 5/rtems-m68k
>> > > 5/rtems-kernel
>> > > 5/rtems-libbsd
>> >
>> >
>> > The libbsd line there might be wrong, but I wouldn’t expect that
>> to affect the availability of <cmath> functions to the C++ compiler.
>> >
>> > Any suggestions?
>> >
>> > Thanks,
>> >
>> > - Andrew
>> >
>> > --
>> > Complexity comes for free, simplicity you have to work for.
>> >
>> > _______________________________________________
>> > users mailing list
>> > users@rtems.org <mailto:users@rtems.org>
>> > http://lists.rtems.org/mailman/listinfo/users
>> <http://lists.rtems.org/mailman/listinfo/users>
>> _______________________________________________
>> users mailing list
>> users@rtems.org <mailto:users@rtems.org>
>> http://lists.rtems.org/mailman/listinfo/users
>> <http://lists.rtems.org/mailman/listinfo/users>
>>
>
> --
> Complexity comes for free, simplicity you have to work for.
>
>
> _______________________________________________
> users mailing list
> users@rtems.org
> http://lists.rtems.org/mailman/listinfo/users
>
_______________________________________________
users mailing list
users@rtems.org
http://lists.rtems.org/mailman/listinfo/users
