Compiling protobuf 3.x fails with use of ‘cmath’ i.s.o. ‘math.h’

[rhermsen]

Hello,

Can someone have a look at the following.
Hope someone can clarify if I’m missing something, or if the compile tools is causing this?

Compiling protobuf 3.x I’m running into an issue if using ‘cmath’.
The failure message: “/google/protobuf/stubs/mathlimits.h:238:20: error: '__builtin_isinf_sign' is not a member of 'std'”
Protobuf 3.x was released about 2 years ago, and have not found others running into this same issue.

The lines of code of protobuf that causes make to fail:

Code: [Select]

#ifndef UTIL_MATH_MATHLIMITS_H__
#define UTIL_MATH_MATHLIMITS_H__

// Note that for Windows we do something different because it does not support
// the plain isinf and isnan.
#if __cplusplus >= 201103L
// GCC 4.9 has a bug that makes isinf and isnan ambigious when both <math.h>
// and <cmath> get pulled into the same translation unit. We use the ones in
// std:: namespace explicitly for C++11
#include <cmath>
#define GOOGLE_PROTOBUF_USE_STD_CMATH
#elif _GLIBCXX_USE_C99_MATH && !_GLIBCXX_USE_C99_FP_MACROS_DYNAMIC
// libstdc++ <cmath> header undefines the global macros and put functions in
// std:: namespace even before C++11. Use the ones in std:: instead too.
#include <cmath>
#define GOOGLE_PROTOBUF_USE_STD_CMATH
#else
#include <math.h>
#endif

Changing this to force math.h solves the make failure.

Code: [Select]

#ifndef UTIL_MATH_MATHLIMITS_H__
#define UTIL_MATH_MATHLIMITS_H__

// Note that for Windows we do something different because it does not support
// the plain isinf and isnan.
#if __cplusplus >= 201103L
// GCC 4.9 has a bug that makes isinf and isnan ambigious when both <math.h>
// and <cmath> get pulled into the same translation unit. We use the ones in
// std:: namespace explicitly for C++11
#include <math.h>
#elif _GLIBCXX_USE_C99_MATH && !_GLIBCXX_USE_C99_FP_MACROS_DYNAMIC
// libstdc++ <cmath> header undefines the global macros and put functions in
// std:: namespace even before C++11. Use the ones in std:: instead too.
#include <math.h>
#else
#include <math.h>
#endif


[Juanito]

explicitly using "-D_GLIBCXX_USE_C99_MATH" doesn't fix things?

[rhermsen]

Hi Juanito,

Indeed export CXXFLAGS="-O2 -pipe -fno-exceptions -march=i486 -mtune=i686 -D_GLIBCXX_USE_C99_MATH" gives the same successful result.

Should I regard this as a solution or a workaround?

[Juanito]

It's a work around for a problem with glibc-2.26

btw, that should be "-Os" and not "-O2" for tinycore 

[rhermsen]

Thanks for catching that.

Another compiler flag related question.

To compile protobuf 3.6.x it looks required to use -march=i686.
According http://wiki.tinycorelinux.net/wiki:creating_extensions I should not use a higher architecture than -march=i486.
Any advise on the use of -march, e.g. I can submit protobuf 3.5.1, which still compiles fine with -march=i486.

[curaga]

If a package requires higher minimum cpu, it's ok to send it that way. For example some browsers require SSE2.

[Rich]

Hi rhermsen

... Another compiler flag related question.

To compile protobuf 3.6.x it looks required to use -march=i686. ...

I couldn't find any i686 minimum requirement. Where did you see that?

If a package requires higher minimum cpu, it's ok to send it that way. For example some browsers require SSE2.

If you do that, make a note of the minimum processor requirement in the  Comments:  section of the  .info  file.

[rhermsen]

Hi Rich,

I have not looked if this is a documented requirement.
With -march=i486 I observe the following error:
'./.libs/libprotobuf.so: undefined reference to `__atomic_fetch_add_8''
A web search pointed to -march, and indeed with -march=i686 protobuf 3.6.0 compiles fine.

[Rich]

Hi rhermsen
I found some references to this being an i386 issue. I also found a  makefile  that addressed it by using  -march=i586  if it
detected an i386 environment. So my question is whether using  -march=i586  will allow it to compile?

[rhermsen]

Hi Rich,

I didn't try -march=i568, will do so.

Now I'm running into an issue with optimization flag -Os (i.s.o. -O2).
I'm looking for the reason why the other extension, which is using protobuf as a dependency, fails to compile.
If I don't find a reason I will gather the details and make an update.

[rhermsen]

Hi Rich,

Indeed with march=i586 protobuf 3.6.0 also finish without errors.

[Rich]

Hi rhermsen
I think you should use the lowest processor that will work. At least with an i586 there won't be any  Illegal Instruction  bugs
reported due to a  CMOV  instruction being compiled in. That's my opinion. See if curaga provides any further guidance.

[rhermsen]

Planning to submit protobuf 3.5.1 for now, which is still supporting -march=i486.
I made a note in the build script for the requirement to use -march=i586 if protobuf 3.6.x is used.

I looked through all issue on protobuf github, but didn't found one regarding issues support for older cpu architectures.