On Sun, Nov 20, 2016 at 1:09 PM, Florian Weimer <fw@xxxxxxxxxxxxx> wrote: > next. It seems to me it contains a statically-linked copy of libm.a, > which really should not happen. I think I can confirm this is what is happening. The other hypothesis I had was that, during libstdc++ compilation _GLIBCXX_HAVE_FREXPL was not defined. This would put in a stub that uses the double version of frexp() in src/c++98/math_stubs_long_double.cc. I confirmed that _GLIBCXX_HAVE_FREXPL is defined to 1 and I took a peek at the assembly code of frexpl in libstdc++.so that was compiled as part of the GCC build. It doesn't look like the wrapper was compiled. I went to go look at the assembly code for frexpl in libm.a and here I came across something confusing: $ grep -rH frexpl /emb-root/usr/lib/arm-linux-gnueabihf/libm.a Binary file /emb-root/usr/lib/arm-linux-gnueabihf/libm.a matches It sure is in there as a symbole. But... $ arm-linux-gnueabihf-objdump -d /emb-root/usr/lib/arm-linux-gnueabihf/libm.a |grep frexpl Comes back with nothing. Odd. Thanks, Mark
