[Openmcl-devel] ICU sketch

[Gary Byers]

The Fink project (<http://www.finkproject.org>) seems to provide
packages which provide headers intended to describe the ICU
functionality that's built into CoreFoundation for recent OSX.  (Some
of the Fink packages seem to only be available in Fink's unstable
trees.)

I've just started to look at it, but it -might- be the case that:
  - this would all be usable without requiring that Fink or any
    other third-party libraries be involved
  - it'd be usable via some combination of (use-interface-dir :icu)
    and (open-shared-library "CoreFoundation.framework/CoreFoundation")
    on OSX and via (open-shared-library "libicu...") on other platforms
    and where the interfaces are generated from the Fink-provided
    headers.
  - the ICU code that Apple builds into CoreFoundation is complete
    or nearly complete (e.g., equivalent to the functionality you'd
    have available if you downloaded corresponding ICU sources and
    built ICU yourself, but possibly installed in some Apple-specific
    places.)

I hadn't even been aware that Apple distributed ICU in any form until
you mentioned it the other day, and naturally started Googling to
try to find out more about what was where.  One link led me to an
email thread, where someone was claiming that they'd have to drop
support for Panther because the version of ICU that Apple shipped
with Panther didn't provide Unicode regular-expression support.  One
interpretation of that message was that the version incorporated into
later OS releases -did- provide that support, which would be good news
from the "complete or nearly complete" standpoint.

The bad news about this is that the version of libicucore.dylib
(and presumably everything built into CoreFoundation) is 32-bit only
on Tiger.  (I guess that the good news is that the iPhone will ship
on time ...)


On Sun, 22 Apr 2007, Takehiko Abe wrote:

> Gary Byers wrote:
>
>>> ;;; About libicucore.dylib:
>>> ;;;
>>> ;;; ICU is preinstalled on Mac OSX Panther as
>>> ;;; /usr/lib/libicucore.dylib (I don't know about Tiger or Leopard)
>>
>> It seems to be there in in later systems as well; I haven't looked
>> extensively, but haven't been able to find any header files that
>> describe what's there.
>
> Header files are not installed on the system. Only libicucore.dylib
> and /usr/share/icudt26b.dat are shipped with OS.
>
> But they are available from darwin-source.
> <http://www.opensource.apple.com/darwinsource/>
>
> For instance, the OS X 10.4.9 Intel version is at:
>
> <http://www.opensource.apple.com/darwinsource/tarballs/other/ICU-
> 6.2.14.tar.gz>
>
> I think it is better to use the official ICU version (for portablity).
>
> I had a problem with it though. I wanted to create a framework
> (e.g. icu.framework) so that I can use it from MCL. The straight build
> creates serveral dylibs and they depend on each other and putting them
> all into a framework folder did not work.
>
> dylibs are:
>
> libicudata.dylib
> libicui18n.dylib
> libicuio.dylib
> libicule.dylib
> libiculx.dylib
> libicutu.dylib
> libicuuc.dylib
>
> This is the dependency:
> [from http://icu-project.org/userguide/design.html]
>
> data library [ libicudata ]
>  |
> common library [ libicuuc ]
>  |
>  *-------------------*
>  |                   |
> i18n library    Layout library
> [libicui18n]    [libicule and libiculx]
>  |
>  |
> Ustdio library
> [ libicuio]
>
> If I put them under non stardard location, open-shared-library fails
> because the dylib cannot find the other lib it depends on.
>
> > (open-shared-library "[...]/libicuuc.dylib")
> --> error reporting libicudata.dylib.36 cannot be found.
>
> $ otool -L libicuuc.dylib
>   libicuuc.dylib:
>         libicuuc.dylib.36 (...)
>         libicudata.dylib.36 (...)
>         /usr/lib/libSystem.B.dylib (...)
>
> I learned that I can use /usr/bin/install_name_tool together with
> @executable_path to force a dylib to look for other dylib in a
> non-standard location (relative to @executable_path). But it never
> worked for MCL. It worked fine with OpenMCL.
>
> There seems to be @load_path keyword (or something like that) to use
> with install_name_tool, which tells a dylib to look for other lib
> relative to its own path, but it is only available on Tiger or later.
>
> It should be possible  to build a standalone shared library like
> apple does, but I don't know much about shared library and gave up.
>
>>
>> (defun icu-version ()
>>    (rlet ((version (:array :uint8_t 4)))
>>      (external-call "_u_getVersion" :address version :void)
>>      (list (paref version (:array :uint8_t) 0)
>>            (paref version (:array :uint8_t) 1)
>>            (paref version (:array :uint8_t) 2)
>>            (paref version (:array :uint8_t) 3))))
>>
>> The one machine I had that ran Panther got zapped by static electricity
>> a few months ago.  Could you please let me know what (ICU-VERSION) returns
>> on Panther ?
>
> CL-USER> (icu-version)
> (2 6 0 0)
>
>>
>> On OSX, CoreFoundation also offers a lot of utilities for dealing
>> with Unicode.
>
> I think many OSX API uses ICU internally.
>
> regards,
> T.
> --
> "Do nothing for as long as possible."
>
>
>