[Openmcl-devel] ICU sketch

Takehiko Abe keke at gol.com
Sun Apr 22 13:06:51 UTC 2007

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.

For instance, the OS X 10.4.9 Intel version is at:


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:


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.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.

"Do nothing for as long as possible."

More information about the Openmcl-devel mailing list