Bug 7646

Summary:	strftime on datetime not works on python3.
Product:	buildroot	Reporter:	Beyonlo <beyonlo>
Component:	Other	Assignee:	unassigned
Status:	RESOLVED FIXED
Severity:	critical	CC:	buildroot
Priority:	P5
Version:	unspecified
Target Milestone:	---
Hardware:	Other
OS:	Linux
Host:		Target:
Build:
Attachments:	The .config of buildroot. The .config of Linux

Description Beyonlo 2014-11-12 12:55:04 UTC

I set python3 to compile in buildroot and the strftime not works:


# uname -a
Linux buildroot 3.13.5 #1 Wed Nov 12 09:42:52 BRST 2014 armv5tejl GNU/Linux
# python3
Python 3.4.1 (default, Nov 12 2014, 09:22:50) 
[GCC 4.4.5] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> from datetime import datetime
>>> datetime.now().strftime("%Y-%m-%d %H:%M:%S")
''
>>> 

As I know, strftime use locale. So I change toolchain to:
"[*] Toolchain has locale support?"

And compile buildroot again. But still not works. The same problem.

However, I tried to do a simple test in C using locale. The strftime works fine in C.

# uname -a
Linux buildroot 3.13.5 #1 Wed Nov 12 09:42:52 BRST 2014 armv5tejl GNU/Linux
# file test2
test2: ELF 32-bit LSB executable, ARM, EABI5 version 1 (SYSV), dynamically linked (uses shared libs), not stripped
# ./test2 
Locale is: (null)
Locale is: (null)
Date is: Fri Sep 12 16:34:33 2014
# 

This is the c example compiled (using arm cross compile) in the host and put in the embedded buildroot:
$ cat test2.c 
#include <locale.h>
#include <stdio.h>
#include <time.h>

int main ()
{
   time_t currtime;
   struct tm *timer;
   char buffer[80];

   time( &currtime );
   timer = localtime( &currtime );

   printf("Locale is: %s\n", setlocale(LC_ALL, "en_US"));
   printf("Locale is: %s\n", setlocale(LC_CTYPE, "en_US.UTF-8"));
   strftime(buffer,80,"%c", timer );
   printf("Date is: %s\n", buffer);

   return(0);
}

Thank you.

Comment 1 Beyonlo 2014-11-12 13:11:25 UTC

Created attachment 5756 [details]
The .config of buildroot.

Comment 2 Beyonlo 2014-11-12 13:12:14 UTC

Created attachment 5762 [details]
The .config of Linux

Comment 3 Beyonlo 2014-11-12 13:18:48 UTC

buildroot$ git show | grep -i commit
commit f21256b86adc88665f6fe1c16672ee7ebf76d6db

Comment 4 Beyonlo 2014-11-12 14:33:27 UTC

buildroot$ git describe
2014.08-rc2-42-gf21256b

Comment 5 Thomas Petazzoni 2014-11-12 22:28:22 UTC

Problem reproduced.

One data point is that python3 has the problem, but not python2. Tested with the same uClibc toolchain.

Comment 6 Thomas Petazzoni 2014-11-12 22:33:00 UTC

Another data point is that it breaks with uClibc (at least the toolchain at http://autobuild.buildroot.org/toolchains/tarballs/br-arm-full-2014.08.tar.bz2), but works with glibc (CodeSourcery ARM 2014.05).

Comment 7 Thomas Petazzoni 2014-11-12 22:45:49 UTC

Hint: since Python 3, Python is using wcsftime() instead of strftime() while Python 2 was using strftime().

Beyonlo, could you write a C program to test wcsftime() and verify that it works?

Comment 8 Beyonlo 2014-11-13 10:36:17 UTC

Hello, I did the tests with wcsftime. I used this example http://www.cplusplus.com/reference/cwchar/wcsftime/

$ cat wcsftime_test1.c 
/* wcsftime example */
#include <wchar.h>
#include <time.h>

int main ()
{
  time_t rawtime;
  struct tm * timeinfo;
  wchar_t buffer [80];

  time ( &rawtime );
  timeinfo = localtime ( &rawtime );

  wcsftime (buffer,80,L"Now it's %I:%M%p.",timeinfo);
  wprintf (L"%ls\n",buffer);

  return 0;
}


Compiled and run on host:
$ ./wcsftime_test1 
Now it's 08:30AM.

Compiled on host (using cross compile - same process used in test2.c) to run on target (buildroot):
# uname -a
Linux buildroot 3.13.5 #1 Wed Nov 12 09:42:52 BRST 2014 armv5tejl GNU/Linux
# ./wcsftime_test1 
# 

Ps: Show nothing on buildroot.

Comment 9 Thomas Petazzoni 2014-11-13 10:45:43 UTC

So wcsftime() is broken in uClibc. It's not a Buildroot bug, but a uClibc bug. We can workaround it for Python 3 by telling Python explicitly to not use wcsftime().

We would need to test if uClibc master is affected or not. If it isn't, then we should backport the patch. It it is, then we should report the bug to upstream uClibc.

Comment 10 Beyonlo 2014-11-13 12:18:13 UTC

Hello.

Well, if the quickly solution is by telling Python explicitly to not use
wcsftime(), I think is a good idea. But I don't know if this solution is the best way.

If you need more tests, please, let me know.

Thank you.

Comment 11 Thomas Petazzoni 2014-11-13 20:31:45 UTC

Here is a quick patch that tells Python3 to not use wcsftime() on uClibc, and it fixes the problem for me:

diff --git a/package/python3/python3.mk b/package/python3/python3.mk
index 2c1ef2a..e242835 100644
--- a/package/python3/python3.mk
+++ b/package/python3/python3.mk
@@ -107,6 +107,10 @@ PYTHON3_CONF_ENV += \
        ac_cv_file__dev_ptc=yes \
        ac_cv_working_tzset=yes
 
+ifeq ($(BR2_TOOLCHAIN_USES_UCLIBC),y)
+PYTHON3_CONF_ENV += ac_cv_func_wcsftime=no
+endif
+
 PYTHON3_CONF_OPTS += \
        --without-ensurepip     \
        --without-cxx-main      \

Comment 12 Thomas Petazzoni 2014-11-13 22:37:39 UTC

Patch to workaround the problem in Python 3 sent to Buildroot: http://lists.busybox.net/pipermail/buildroot/2014-November/112005.html

uClibc bug reproduced with uClibc master, and bug reported to upstream uClibc: http://lists.uclibc.org/pipermail/uclibc/2014-November/048718.html.

Since I don't expect the uClibc folks to react quickly, I would propose to mark this bug as fixed once the Python 3 workaround is committed in Buildroot.

Beyonlo, can you test the Buildroot patch for Python 3, and report if it works for you (it works for me, so I'm pretty sure it's ok, but still). Thanks!

Comment 13 Thomas Petazzoni 2014-11-14 08:28:56 UTC

Patch work-arounding the problem for Python 3 has been applied, see http://git.buildroot.net/buildroot/commit/?id=5ad4ac083276b3504889c39351a56d947f172b5f.

The same problem can occur with other packages, but unfortunately, there's not much we can do at this point, except waiting for the uClibc folks to react.

Since the original problem related to Python 3 is now fixed, I'm closing this bug.