Bug 436364 – dev-lib/icu-49.1.{1,2}: fails to compile on uclibc due to undefined __timezone in source/common/putil.cpp

• Status: RESOLVED FIXED
• Product: Gentoo Linux

[Description Anthony Basile 2012-09-26 23:15:31 UTC]

In common/putilimp.h we have

    #ifdef U_TIMEZONE
        /* Use the predefined value. */
    #elif U_PLATFORM_IS_LINUX_BASED
    #   define U_TIMEZONE __timezone
    #elif U_PLATFORM_USES_ONLY_WIN32_API
    #   define U_TIMEZONE _timezone
    #elif U_PLATFORM == U_PF_BSD && !defined(__NetBSD__)
       /* not defined */
    #elif U_PLATFORM == U_PF_OS400
       /* not defined */
    #else
    #   define U_TIMEZONE timezone
    #endif


So on a linux platform where U_PLATFORM_IS_LINUX_BASED is defined, we have

    #   define U_TIMEZONE __timezone

but __timezone is a pure glibc-ism and fails on uclibc systems.  One approach to fixing this follows a suggestion for a similar fix for ANDROID where putil.cpp is patched, see

    http://stackoverflow.com/questions/9780553/compiling-icu-for-android-timezone-was-not-declared-in-this-scope

and

    http://pastebin.com/U6cCQq83


Transporting that fix to uclibc, we get a patch against source/common/putil.cpp as follows:

--- icu.orig/source/common/putil.cpp	2012-06-01 10:52:46.000000000 -0400
+++ icu/source/common/putil.cpp	2012-09-26 18:22:04.074820300 -0400
@@ -633,7 +633,7 @@
 U_CAPI int32_t U_EXPORT2
 uprv_timezone()
 {
-#ifdef U_TIMEZONE
+#if defined(U_TIMEZONE) && !defined(__UCLIBC__)
     return U_TIMEZONE;
 #else
     time_t t, t1, t2;


Alternatively, we could migrate the check for __UCLIBC__ to common/putilimp.h.  Not sure which is best.

@Arfrever, if you can advise, I'll push this forward uptream.

[Comment 1 Anthony Basile 2012-09-26 23:43:38 UTC]

Okay upstream bug opened:

    http://bugs.icu-project.org/trac/ticket/9605

[Comment 2 Anthony Basile 2013-03-06 21:04:32 UTC]

(In reply to comment #1)
> Okay upstream bug opened:
> 
>     http://bugs.icu-project.org/trac/ticket/9605

Please not this was fixed upstream.  If I'm reading their report correctly, the fix is in 51.1 (release).

Can we push that out and I'll test and close this bug.

[Comment 3 Anthony Basile 2013-04-05 11:39:46 UTC]

ping @everyone!   I'd like to get 51.1 or above in the tree.  Any objections to me doing it?

[Comment 4 Tomáš Chvátal (RETIRED) 2013-04-05 11:42:14 UTC]

(In reply to comment #3)
> ping @everyone!   I'd like to get 51.1 or above in the tree.  Any objections
> to me doing it?

Go ahead mate. Just test it in office and try to find something LTR.

[Comment 5 Anthony Basile 2013-04-06 15:49:29 UTC]

(In reply to comment #4)
> (In reply to comment #3)
> > ping @everyone!   I'd like to get 51.1 or above in the tree.  Any objections
> > to me doing it?
> 
> Go ahead mate. Just test it in office and try to find something LTR.

Okay its on the tree and it does 51.1 does indeed fix this bug on uclibc.