[FriBidi] Win32 (MinGW) work
fridrich.strba at bluewin.ch
Thu Jul 7 05:13:50 PDT 2005
Hello, I just wanted to say following:
1) It is very likely that libwpd, http://libwpd.sf.net, a project that I
code for, will have to use fribidi(for AbiWord) and/or icu (for OOo) in
order to reorder the WordPerfect text before giving it to an unicode
enabled application. WordPerfect stores all characters in visual order
(the Arabic and Hebrew glyphs are handled as mere pictures).
2) Since we are shipping also a Windows version of libwpd, I tried to
build the CVS module fribidi2 with MinGW and I managed after a small
patching of the build system:
(a) if the libfribibi-char-sets.a remains built as it is now, in "bin"
directory, in LDFLAGS, charset/libfribidi-char-sets.la must be before
lib/libfribidi.la. In the oposite case, the linker will fail with
(b) the fribidi_version_info symbol has to be in the fribidi.def file.
If it is not, the linking in "bin" directory fails with undefined
symbol. I will still try whether one cannot just simply ommit the
fribidi.def file, since MinGW gcc is having an auto import/export
capacity. But, I have to investigate more, since if I am not mistaken,
_const_ char * is not correctly exported, but it remains to be confirmed.
(c) if the configure process does not find the sys/times.h header, the
function utime(void) in fribidi-benchmark.c will fail, with tb and times
"used prior to declaration". This patch makes the file build with a hack
making (in this case) the utime return "0" always.
3) When I was reading the code, I realized that it is very well possible
to separate the libfribidi.so and an eventual libfribidi-char-sets.so.
The only link between the two is the "#include <fribidi-char-sets.h> in
fribidi.h header. I tried in this patch something: to create two
libraries that do not depend on each other. This would allow the
configure of an application to know whether the system has both
libfribidi.so and libfribidi-char-sets.so and act accordingly. Without
the need to check whether libfribidi.so contains
fribidi_charset_to_unicode, etc. It would also mean that the result
would be two separate DLLs for Windows and an application should just
ship with one if they do not use the conversion routines.
I am attaching the patch. You are free to use it or to discard it.
Concerning the Win32 "porting" work, if you are interested, I can do
something with it. BTW: I tried to build the DLLs of 0.10.5 using the
include MSVC project files and it is possible with some small patching
and leaving out wcwidth.c that has all problems getting compiled.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 7242 bytes
Desc: not available
Url : http://lists.freedesktop.org/archives/fribidi/attachments/20050707/bf63982f/fribidi2.bin
More information about the fribidi