sys/cbor: fix compilation with newlib

[kYc0o]

Fixes #7411 and maybe #7287.

In some arm-none-eabi-gcc libc strptime in<time.h> is guarded by __GNU_VISIBLE define, which is defined while setting the define _GNU_SOURCE, otherwise strptime is not defined and thus any usage of it fails to compile.

This is the case in cbor, which doesn't include <time.h> explicitly, as well as setting the define _GNU_SOURCE is missing.

This PR fixes that.

[miri64]

I think we could better model this. As a (pseudo-)module (e. g. posix_time) for instance.

[miri64]

Why non-Darvin only? Is OSX not using newlib for cross-compiling?

[kYc0o]

Because this is not a OS X related issue, but gcc-arm-none-eabi libc (and maybe also avr-gcc, cannot test because my compiler is broken).

[miri64]

But uname - s returns info about the host system, not the toolchain in use.

[kYc0o]

True, let me check why it works then.

[cladmi]

The non darwin guard was to prevent multiple definition: e867d83e
However the test only made sense for native.

I also had the problem with arm-gcc 4.9.4, but not with 6.3.1 anymore.

The new GNU_SOURCE you set is only done for Darwin (it is an ifneq). So it does not fixes linux + arm-gcc 4.9.4.

[kYc0o]

I think we could better model this. As a (pseudo-)module (e. g. posix_time) for instance.

As far as I understand this is not a POSIX function but a GNU extension, thus, I don't think this should be a POSIX pseudo module.

[miri64]

As far as I understand this is not a POSIX function but a GNU extension, thus, I don't think this should be a POSIX pseudo module.

At least the latest POSIX spec defines it

[kYc0o]

Well, the conclusion of my tests are:

• In non-Darwin machines (e.g. Linux) _XOPEN_SOURCE must be defined to use strptime.
• In Darwin _XOPEN_SOURCE is defined by default when building for native.
• Thus, the previous check disables _XOPEN_SOURCE when building for non-native platforms, however
• _GNU_SOURCE is the actual define which enables the strptime function in some (new) arm-none-eabi-gcc.

I pushed a fixup which defines _GNU_SOURCE only if cbor_ctime is used.

[jnohlgard]

Does it work if you define _DEFAULT_SOURCE instead of XOPEN_SOURCE or GNU_SOURCE?

[miri64]

@gebart not sure... From the glibc doc (couldn't find anything for newlib with my quick search):

Macro: _DEFAULT_SOURCE
If you define this macro, most features are included apart from X/Open, LFS and GNU extensions: the effect is to enable features from the 2008 edition of POSIX, as well as certain BSD and SVID features without a separate feature test macro to control them. Defining this macro, on its own and without using compiler options such as -ansi or -std=c99, has the same effect as not defining any feature test macros; defining it together with other feature test macros, or when options such as -ansi are used, enables those features even when the other options would otherwise cause them to be disabled.

[miri64]

@kYc0o have a look at kYc0o#4 for a cleaner integration into our build system.

[kYc0o]

Hmm... I suppose I should remove the merge commit is it?

[miri64]

ACK, please rebase so that the merge commit disappears.

[miri64]

(and squash your own ;-))

[kYc0o]

Squashed and rearranged commits.

[kYc0o]

Go!

[miri64]

Please provide backport ;-)

[miri64]

Backport provided and already merged in #7819