C++ and feature guards Warning Question

C++ and feature guards Warning Question

[Joel Sherrill]

Hi

Trying to compile an open source package for RTEMS, I
came across something I need help to figure out how
best to address. The package is in C++ and giving a
lot of warnings on methods which I would have thought
are prototyped. But clearly the compiler settings
are tripping the guards different than the package
authors expect.

Native GCC on CentOS 7 with glibc gives no warnings.
It could easily be a GCC version side-effect.

==========================
#include <stdlib.h>

int f(char *s)
{
   return mkstemp(s);
}
==========================

Warnings with i386-rtems GCC and newilb:

$ i386-rtems4.12-gcc -c j.cc
$ i386-rtems4.12-gcc -std=c++11 -c j.cc
j.cc: In function 'int f(char*)':
j.cc:5:19: error: 'mkstemp' was not declared in this scope
    return mkstemp(s);
$ i386-rtems4.12-gcc -std=c++03 -c j.cc
j.cc: In function 'int f(char*)':
j.cc:5:19: error: 'mkstemp' was not declared in this scope
    return mkstemp(s);
$ i386-rtems4.12-gcc --version
i386-rtems4.12-gcc (GCC) 6.3.0 20161221 (RTEMS 4.12, RSB 4c5eb8969451c4ea0997b3caa98bfe80fe15da69, Newlib 2.5.0.20170228)

Native GCC and glibc results:

$ gcc -std=c++03 -c j.cc
$ gcc -std=c++11 -c j.cc
$ gcc -std=c++11 ^C j.cc
$ gcc --version
gcc (GCC) 4.8.5 20150623 (Red Hat 4.8.5-11)

Suggestions on what to do to eliminate the warnings is
appreciated.

Thanks.

-- 
Joel Sherrill, Ph.D.             Director of Research & Development
joel.sherrill@OARcorp.com        On-Line Applications Research
Ask me about RTEMS: a free RTOS  Huntsville AL 35806
Support Available                (256) 722-9985

Re: C++ and feature guards Warning Question

[Chris Johns]

On 06/04/2017 07:18, Joel Sherrill wrote:
>
> Trying to compile an open source package for RTEMS, I
> came across something I need help to figure out how
> best to address. The package is in C++ and giving a
> lot of warnings on methods which I would have thought
> are prototyped. But clearly the compiler settings
> are tripping the guards different than the package
> authors expect.
>
> Native GCC on CentOS 7 with glibc gives no warnings.
> It could easily be a GCC version side-effect.
>
> ==========================
> #include <stdlib.h>
>
> int f(char *s)
> {
>   return mkstemp(s);
> }
> ==========================
>
> Warnings with i386-rtems GCC and newilb:
>
> $ i386-rtems4.12-gcc -c j.cc
> $ i386-rtems4.12-gcc -std=c++11 -c j.cc
> j.cc: In function 'int f(char*)':
> j.cc:5:19: error: 'mkstemp' was not declared in this scope
>    return mkstemp(s);
> $ i386-rtems4.12-gcc -std=c++03 -c j.cc
> j.cc: In function 'int f(char*)':
> j.cc:5:19: error: 'mkstemp' was not declared in this scope
>    return mkstemp(s);
> $ i386-rtems4.12-gcc --version
> i386-rtems4.12-gcc (GCC) 6.3.0 20161221 (RTEMS 4.12, RSB
> 4c5eb8969451c4ea0997b3caa98bfe80fe15da69, Newlib 2.5.0.20170228)
>
> Native GCC and glibc results:
>
> $ gcc -std=c++03 -c j.cc
> $ gcc -std=c++11 -c j.cc
> $ gcc -std=c++11 ^C j.cc
> $ gcc --version
> gcc (GCC) 4.8.5 20150623 (Red Hat 4.8.5-11)
>
> Suggestions on what to do to eliminate the warnings is
> appreciated.
>

I built the code on FreeBSD with clang and the result is the same as Linux:

$ cc -std=c++03 -c j.cc
$ cc -std=c++11 -c j.cc
$ cc --version
FreeBSD clang version 3.8.0 (tags/RELEASE_380/final 262564) (based on 
LLVM 3.8.0)
Target: x86_64-unknown-freebsd11.0
Thread model: posix
InstalledDir: /usr/bin

Adding -save-temps to the builds I see `mkstemp` is guarded with:

#if __MISC_VISIBLE || __POSIX_VISIBLE >= 200112 || __XSI_VISIBLE >= 4

and FreeBSD has:

#if __POSIX_VISIBLE >= 200809 || __XSI_VISIBLE

I hope this helps.

Chris

Re: C++ and feature guards Warning Question

[Yaakov Selkowitz]

On 2017-04-05 16:18, Joel Sherrill wrote:
> Trying to compile an open source package for RTEMS, I
> came across something I need help to figure out how
> best to address. The package is in C++ and giving a
> lot of warnings on methods which I would have thought
> are prototyped. But clearly the compiler settings
> are tripping the guards different than the package
> authors expect.
>
> Native GCC on CentOS 7 with glibc gives no warnings.

G++ defines _GNU_SOURCE on glibc targets, meaning that -std=c++NN is, 
contrary to the documentation, *not* strict ISO C++:

https://github.com/gcc-mirror/gcc/blob/master/gcc/config/gnu-user.h#L105

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=51749

Per my comments in that BZ, I believe there is a better way of doing 
this, but it will require patches to both gcc and glibc.  Once this is 
done -- and while it's on my wishlist, I don't know when I'll have time 
to work on it -- software will finally stop taking -std=c++NN for 
granted.  In the meantime, building for newlib/Cygwin/RTEMS is going to 
be different from glibc in some cases.

In any case, the fix is either to use proper feature test macros, or use 
-std=gnu++NN instead.  I have had to do this on a number of occasions 
while building software for Cygwin.

-- 
Yaakov

Re: C++ and feature guards Warning Question

[Joel Sherrill]

On 4/6/2017 12:25 AM, Yaakov Selkowitz wrote:
> On 2017-04-05 16:18, Joel Sherrill wrote:
>> Trying to compile an open source package for RTEMS, I
>> came across something I need help to figure out how
>> best to address. The package is in C++ and giving a
>> lot of warnings on methods which I would have thought
>> are prototyped. But clearly the compiler settings
>> are tripping the guards different than the package
>> authors expect.
>>
>> Native GCC on CentOS 7 with glibc gives no warnings.
>
> G++ defines _GNU_SOURCE on glibc targets, meaning that -std=c++NN is,
> contrary to the documentation, *not* strict ISO C++:
>
> https://github.com/gcc-mirror/gcc/blob/master/gcc/config/gnu-user.h#L105
>
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=51749
>
> Per my comments in that BZ, I believe there is a better way of doing
> this, but it will require patches to both gcc and glibc.  Once this is
> done -- and while it's on my wishlist, I don't know when I'll have time
> to work on it -- software will finally stop taking -std=c++NN for
> granted.  In the meantime, building for newlib/Cygwin/RTEMS is going to
> be different from glibc in some cases.
>
> In any case, the fix is either to use proper feature test macros, or use
> -std=gnu++NN instead.  I have had to do this on a number of occasions
> while building software for Cygwin.
>

This was for poppler and this minor change to their configure.ac
improved the build warnings immensely.

These issues are always subtle. Thanks for providing the insight.
I did suspect that newlib might be ahead of the curve on precisely
following the standards.

--joel

Re: C++ and feature guards Warning Question

[Jeffrey Walton]

> ...
> Native GCC and glibc results:
>
> $ gcc -std=c++03 -c j.cc
> $ gcc -std=c++11 -c j.cc
> $ gcc -std=c++11 ^C j.cc
> $ gcc --version
> gcc (GCC) 4.8.5 20150623 (Red Hat 4.8.5-11)
>
> Suggestions on what to do to eliminate the warnings is
> appreciated.

Defining _XOPEN_SOURCE to 600 or 700 can usually squash the problems
in userland programs and libraries. I found one C++ library where it
does not.

I'm not sure how GCC will react to the define because I don't build
the compiler from sources.

Jeff