ICU port?
Steven R. Loomis
srl at icu-project.org
Sun Dec 11 07:24:12 UTC 2016
El 12/10/16 7:04 AM, "Tijl Coosemans" <tijl at freebsd.org> escribió:
>On Fri, 09 Dec 2016 15:44:47 -0800 "Steven R. Loomis" <srl at icu-project.org> wrote:
>> I came across this address (though it seems to be a generic one)
>> on http://portsmon.freebsd.org/portoverview.py?category=devel&portname=icu
>> and https://svnweb.freebsd.org/ports/head/devel/icu/
>>
>> I work on ICU. 58.2 is shipping today (hopefully).
>>
>> It seems there are a bunch of patches in
>> https://svnweb.freebsd.org/ports/head/devel/icu/files/
>>
>> It would be great to get these pushed upstream to ICU.
>>
>> Any way we can try to do that?
>> ICU’s CLA is at https://ssl.icu-project.org/trac/wiki/IcuDownstreams#cla
>> for accepting patches.
>
>Feel free to commit them.
Could you consider signing the CLA at the bottom of http://icu-project.org/trac/#cla ? It’s 1-click if you have a Github id.
>
>The Makefile patches fix installation of static libraries. INSTALL-L
>is equal to INSTALL_PROGRAM which may include the -s flag to strip
>(debug) symbols. Stripping removes the .symtab section from ELF files
>which is ok for programs and dynamically linked libraries (which also
>have a .dynsym section listing exported symbols), but not for static
>libraries. If you strip a static library it will no longer export any
>symbols, i.e. the output of "readelf -s libfoo.a" will be empty.
Sounds like a good one to upstream also.
>patch-common_umutex.cpp:
>This code is compiled conditionally and one of the cases is a c++11
>compiler without <atomic> header. uio.fState is an atomic variable and
>cannot be read directly. I used umtx_loadAcquire in the patch because
>that's what's used elsewhere to read fState.
OK. Why would <atomic> not be available?
>patch-common_unicode_platform.h:
>I believe that since a few versions ICU is compiled with _XOPEN_SOURCE
>defined. This makes our libc headers more strictly standards compliant
>so they don't define BYTE_ORDER and BIG_ENDIAN. _BYTE_ORDER and
>_BIG_ENDIAN are still defined though. The patch should probably just
>add them without removing the former. You should also check if other
>operating systems define these macros and if their definition is
>compatible or not.
This is a good idea.
>patch-common_unicode_uconfig.h:
>This is just local FreeBSD configuration. You probably don't want to
>commit this.
Ok
>
>patch-config_mh-bsd-gcc:
>Makes this file more similar to the Linux one.
Sure, this sounds like a good one to take upstream.
>patch-r39484:
>Patch from https://ssl.icu-project.org/trac/ticket/12827
Ok, just a backport.
Thanks!
P.s. 58.2 just shipped.
More information about the freebsd-office
mailing list