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