Hello all,
when have tested recent master branch (fbe59f7c6756edc2952b13167893b85fe6e7aecb)
build configured for lpc17xx_ea_ram BSP, I am experiencing next error for my
code with networking enabled. It seems to be related to add of ping command.
Even addition of -lm to my LDFLAGS does not help
GCC call from OMK based makefile
arm-rtems4.11-gcc --pipe -B/opt/rtems4.11/arm-rtems4.11/lpc17xx_ea_ram/lib/ \
-specs bsp_specs -qrtems -march=armv7-m -mthumb \
-I
/home/pi/repo/rtems/build/arm-lpc17xx_ea_ram/omk-template/_compiled/lpc17xx_ea_ram/include
\
-Wall -O2 -g init.o task_1.o \
-L/home/pi/repo/rtems/build/arm-lpc17xx_ea_ram/omk-template/_compiled/lpc17xx_ea_ram/lib
\
-lbar -lnfs -lm -o
/home/pi/repo/rtems/build/arm-lpc17xx_ea_ram/omk-template/_compiled/lpc17xx_ea_ram/bin/appnet
Error reported
/opt/rtems4.11/arm-rtems4.11/lpc17xx_ea_ram/lib/librtemscpu.a(libshell_a-main_ping.o):
In function `g_finish':
/home/pi/repo/rtems/build/arm-lpc17xx_ea_ram/rtems/arm-rtems4.11/c/lpc17xx_ea_ram/cpukit/libmisc/../../../../../../../../git/rtems/c/src/../../cpukit/libmisc/shell/main_ping.c:1642:
undefined reference to `sqrt'
collect2: error: ld returned 1 exit status
make[3]: ***
[/home/pi/repo/rtems/build/arm-lpc17xx_ea_ram/omk-template/_compiled/lpc17xx_ea_ram/bin/appnet]
Error 1
make[2]: *** [binary-pass-this-dir] Error 2
make[1]: *** [binary-pass-appnet-subdir] Error 2
make: *** [binary-pass] Error 2
I have investigated how collect is called and even tried to modify it by adding
libm.a
/usr/arm-rtems4.11/gcc/4.9.1/bin/../libexec/gcc/arm-rtems4.11/4.9.1/collect2 \
-dc -dp -N -o
/home/pi/repo/rtems/build/arm-lpc17xx_ea_ram/omk-template/_compiled/lpc17xx_ea_ram/bin/appnet
\
/opt/rtems4.11/arm-rtems4.11/lpc17xx_ea_ram/lib/start.o \
/usr/arm-rtems4.11/gcc/4.9.1/bin/../lib/gcc/arm-rtems4.11/4.9.1/thumb/armv7-m/crti.o
\
/usr/arm-rtems4.11/gcc/4.9.1/bin/../lib/gcc/arm-rtems4.11/4.9.1/thumb/armv7-m/crtbegin.o
\
-e _start \
-L/home/pi/repo/rtems/build/arm-lpc17xx_ea_ram/omk-template/_compiled/lpc17xx_ea_ram/lib
\
-L/usr/arm-rtems4.11/gcc/4.9.1/bin/../lib/gcc/arm-rtems4.11/4.9.1/thumb/armv7-m
\
-L/usr/arm-rtems4.11/gcc/4.9.1/bin/../lib/gcc/arm-rtems4.11/4.9.1/../../../../arm-rtems4.11/lib/thumb/armv7-m
\
-L/opt/rtems4.11/arm-rtems4.11/lpc17xx_ea_ram/lib
-L/usr/arm-rtems4.11/gcc/4.9.1/bin/../lib/gcc/arm-rtems4.11/4.9.1 \
-L/usr/arm-rtems4.11/gcc/4.9.1/bin/../lib/gcc \
-L/usr/arm-rtems4.11/gcc/4.9.1/bin/../lib/gcc/arm-rtems4.11/4.9.1/../../../../arm-rtems4.11/lib
\
init.o task_1.o -lbar -lnfs \
/usr/arm-rtems4.11/lib/thumb/armv7-m/libm.a \
--start-group -lgcc --start-group -lrtemsbsp -lrtemscpu -lc -lgcc
--end-group \
-T /opt/rtems4.11/arm-rtems4.11/lpc17xx_ea_ram/lib/linkcmds --end-group \
/usr/arm-rtems4.11/gcc/4.9.1/bin/../lib/gcc/arm-rtems4.11/4.9.1/thumb/armv7-m/crtend.o
\
/usr/arm-rtems4.11/gcc/4.9.1/bin/../lib/gcc/arm-rtems4.11/4.9.1/thumb/armv7-m/crtn.o
What seems to be problem cause is the fact, that bsp_specs adds libraries
group including librtemscpu.a after libm.a. Because libm.a is not in the group
then repeated search for sqrt() is not run after ping inclussion.
Adding libm at the end of manually crafted collect2 line helps
/usr/arm-rtems4.11/lib/thumb/armv7-m/libm.a
Sequence of link specification
%{qrtems: --start-group -lrtemsbsp -lrtemscpu -lc -lgcc --end-group %{!qn
is compiled in GCC driver /usr/arm-rtems4.11/gcc/4.9.1/bin/gcc, which is
defined in GCC sources
gcc-4.9.1/gcc/config/rtems.h
#undef LIB_SPEC
#define LIB_SPEC "%{!qrtems: " STD_LIB_SPEC "} " \
"%{!nostdlib: %{qrtems: --start-group \
-lrtemsbsp -lrtemscpu \
-lc -lgcc --end-group %{!qnolinkcmds: -T linkcmds%s}}}"
If float funtions support is needed by rtems core libraries then
"-lm" or "libm.a" has to be included in this define.
The problem is caused by "ping" statistic/standard deviation computation
in there
cpukit/libmisc/shell/main_ping.c:1642
if (nreceived && timing) {
double n = nreceived + nrepeats;
double avg = tsum / n;
double vari = tsumsq / n - avg * avg;
(void)printf(
"round-trip min/avg/max/stddev = %.3f/%.3f/%.3f/%.3f ms\n",
tmin, avg, tmax, sqrt(vari));
}
I expect that problem can be hidden on hardware floating point
targets because sqrt is inlined/translated directly to FPU
instructions.
If the politics is not to require/pull in FPU support for core
libraries then I suggest to replace whole statistic computation
by fixed point/fraction based code or at least use integer/long based
sqrt replacement.
May it be that problem is specific to my local toolchain build
and makefiles used but my guess is that it is generic.
Best wishes
Pavel
_______________________________________________
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
