strptime dissapeared on 3.0.0

[asturcon3]

Arduino last IDE, esp8266 just updated to 3.0.0, and I'm getting undefined error for strptime. After playing with and without XSI_VISIBLE, searching the includes, trying with and without time.h and timelib.h, I'm doing a workaround (parsing the old way) and letting you know.

[earlephilhower]

As requested in the template you deleted, please provide an MCVE so we can reproduce. Otherwise there's not much we can do.

FWIW, libc.a looks to contain strptime still:

$ nm libc.a
....


lib_a-strptime.o:
         U _C_time_locale
         U _ctype_
00000000 r _DAYS_BEFORE_MONTH
         U __errno
00000044 t first_day
         U __global_locale
00000000 t is_leap_year
         U localtime_r
00000090 t match_string
         U __modsi3
         U strlen
         U strncasecmp_l
00000888 T strptime
000000ec T strptime_l
         U strtol_l
         U strtoll_l
00000000 R tm_year_base

[dok-net]

#3522
Building that MCVE on current master b4774ed:

sptime.ino: 10:9: error: 'strptime' was not declared in this scope; did you mean 'strftime'?
   %S", &tm) == NULL) midnight = 0
   |         ^~~~~~~~
   |         strftime

In tools/xtensa-lx106-elf/xtensa-lx106-elf/include/sys/features.h,

#ifdef _GNU_SOURCE
#define __GNU_VISIBLE           1
#else
#define __GNU_VISIBLE           0
#endif

always defines __GNU_VISIBLE to 0, thereby disabling strptime and strptime_l. You can define _GNU_SOURCE all you like in your sketch, it doesn't change.

[dok-net]

It builds fine with release 2.7.4

[earlephilhower]

@asturcon3 I can repro with the example @dok-net , but you don't need to write your own version. Just add this line to your code:

extern "C" char *strptime (const char *__restrict, const char *__restrict, struct tm *__restrict);

Basically, the code is there in the library, but the defines in the new build seem to disable the prototype from being parsed. This is most likely related to the Newlib 4.0.0 release (about 5 years newer than the on in 2.7.4), and needs some digging. The above prototype will get you goin in the meantime.

[tobozo]

not sure if it's related but memrchr is gone too and the __GNU_VISIBLE macros seems involved

adding this to my sketch solved the issue:

extern "C" void *memrchr (const void *__restrict, int __restrict, size_t __restrict);

[d-a-v]

It seems that defining _GNU_SOURCE would make these two functions visible.

diff --git a/platform.txt b/platform.txt
index 5b4a1442..88d9c82b 100644
--- a/platform.txt
+++ b/platform.txt
@@ -56,7 +56,7 @@ compiler.path={runtime.tools.xtensa-lx106-elf-gcc.path}/bin/
 compiler.sdk.path={runtime.platform.path}/tools/sdk
 
 compiler.libc.path={runtime.platform.path}/tools/sdk/libc/xtensa-lx106-elf
-compiler.cpreprocessor.flags=-D__ets__ -DICACHE_FLASH -U__STRICT_ANSI__ "-I{compiler.sdk.path}/include" "-I{compiler.sdk.path}/{build.lwip_include}" "-I{compiler.libc.path}/include" "-I{build.path}/core"
+compiler.cpreprocessor.flags=-D__ets__ -DICACHE_FLASH -U__STRICT_ANSI__ -D_GNU_SOURCE "-I{compiler.sdk.path}/include" "-I{compiler.sdk.path}/{build.lwip_include}" "-I{compiler.libc.path}/include" "-I{build.path}/core"
 
 compiler.c.cmd=xtensa-lx106-elf-gcc
 compiler.c.flags=-c {compiler.warning_flags} -std=gnu17 {build.stacksmash_flags} -Os -g -free -fipa-pta -Wpointer-arith -Wno-implicit-function-declaration -Wl,-EL -fno-inline-functions -nostdlib -mlongcalls -mtext-section-literals -falign-functions=4 -MMD -ffunction-sections -fdata-sections {build.exception_flags} {build.sslflags} {build.mmuflags} {build.non32xferflags}

diff --git a/tools/platformio-build.py b/tools/platformio-build.py
index d8a97982..35a88fe4 100644
--- a/tools/platformio-build.py
+++ b/tools/platformio-build.py
@@ -73,6 +73,7 @@ env.Append(
         "-mtext-section-literals",
         "-falign-functions=4",
         "-U__STRICT_ANSI__",
+        "-D_GNU_SOURCE",
         "-ffunction-sections",
         "-fdata-sections",
         "-Wall",

[earlephilhower]

@tobozo @asturcon3 @dok-net can you please give #8147 a try and report back? Simple tests look good to me w/it.

[dok-net]

https://stackoverflow.com/questions/5582211/what-does-define-gnu-source-imply makes me seriously doubt that this is such a good idea for an embedded platform. Lots of function prototypes that make no sense at all on the ESPs are then available... Perhaps this needs a little more investigation.

For instance, -D_XOPEN_SOURCE (possibly with a value assignment, too) would/should enable strptime just the same.

[dok-net]

And as a case in point, the above mentioned memrchr appears, speaking from quick research, to be unsupported on Windows. If this affects cross/"host" builds, it should not be wanted. Just because something was once available, doesn't mean it wasn't so in error.

[dok-net]

Furthermore, strptime is not available, neither in prototype nor in binary linker library, for Arduino AVR (targetting ATmega328P).

[tobozo]

@earlephilhower adding a gnu flag to the platform.txt has the same positive effect as adding the extern C signature in my sketch.

@dok-net I've compared binary size and dynamic memory size at the end of compilation between the two tests, although compiling with the gnu flag takes a little more time, both builds produce similar results.

I tried -D_XOPEN_SOURCE to no success (even lost strdup) but I'm not familiar with that flag so I probably missed something.

[dok-net]

@earlephilhower @tobozo I didn't think I would have to provide the full solution instead of a few hints :-) Here it is anyway, PR #8150 is based on and supersedes the one by d-a-v #8147

[tobozo]

@dok-net thanks for the link, I'm still getting this at compilation even after adding -D_XOPEN_SOURCE=700 -D_DEFAULT_SOURCE flags (I was using =600 but it doesn't change much):

error: 'memrchr' was not declared in this scope; did you mean 'memchr'?

It's still fixed by using extern C though

[earlephilhower]

Nobody is making people use the extended functionality, so this won't actively hurt folks or make sketches bigger.

If authors do need to do what strptime does, it's definitely better to let them use the tested, documented, quasi-standard calls already available thanks to the Newlib project than to have them reinvent the wheel.