[FriBidi] Win32 (MinGW) work

[Fridrich Strba]

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 
unresolved symbols
(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.

Cheers

Fridrich Strba
-------------- next part --------------
A non-text attachment was scrubbed...
Name: fribidi2.diff
Type: text/x-patch
Size: 7242 bytes
Desc: not available
Url : http://lists.freedesktop.org/archives/fribidi/attachments/20050707/bf63982f/fribidi2.bin