Hi Cristophe, I'm glad you got the compilation to work for you. Regarding the static build, you should beware of the requirements of the LGPL license. If you compile static you will have to provide all of your sources that link to fribidi, to anyone that you provide your final exe to. If you use the shared library, then you can create closed source programs. You should check the license text for the exact details. Whether this is relevant all depends on whether you are creating free or closed source software. Cheers, Dov <div>On 08/04/2008, Christophe GISQUET <<a href="mailto:christophe.gisquet@free.fr">christophe.gisquet@free.fr</a>> wrote:<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"> Hello, my target is to build fribidi2 (from tarball of 0.19.1) by both mingw and Microsoft Visual Studio Express (ie free-as-in-beer). I think I've mostly succeeded. In the later environment, I'm using the 2005 edition, not caring about the latest versions. I came across a number of difficulties: 1) Static vs dynamic library Configure script, even after being rebuilt with my local versions of autotools (automake 1.9.5 and autoconf 2.59 which aren't the newest, I know), won't let me deactivate shared libraries (aka dll). At best, it builds both static and dynamic. This is troublesome, because symbols from a shared library and a static library aren't named the same under Windows. This is somewhat handled by FRIBIDI_ENTRY define, except that it is forced to __declspec(import), which assumes dynamic: <a href="http://msdn2.microsoft.com/en-us/library/8fskxacy%28VS.80%29.aspx" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">http://msdn2.microsoft.com/en-us/library/8fskxacy(VS.80).aspx</a> Indeed, that's what configure tries to force. In that case, fribidi2 isn't the only module behaving like this, and anyway, I guess it's up to me to assume my own choices (ease of packaging). 2) API partly deprecated It seems fribidi_utf8_to_unicode and fribidi_unicode_to_utf8 are no longer directly available. Is it correct? I don't think so, because the symbol is really present in the library, so that would be a waste to not make it available. 3) struct tms Is indeed unavailable under Windows. This is only a test program but yet you can find a patch attached to this mail so as to use the more classical clock function. I'll let you comment on the comments in this file instead of repeating them. Anyway, I haven't tested the test programs, so I don't know if this is correct. 4) Support for Visual Studio compiler I simply reused the generated config.h and fribidi-config.h from mingw, and edited them to match the VS environment. I then produced project and solution files (the equivalent of a Makefile) to only build a static library (no dynamic one, not test programs). This suits my needs, but to have it actually link with a program, the FRIBIDI_ENTRY define must be defined as empty. About that last point, I'm not sure how much time I'd like to invest into having it work with the normal (shared lib) configuration. The result is that the mingw version works (I could verify the correct glyphs are output for a string in farsi). I couldn't verify the visual version because the program I use for testing has a broken support for gettext, and I haven't yet been able to fix it... _______________________________________________ fribidi mailing list <a onclick="return top.js.OpenExtLink(window,event,this)" href="mailto:fribidi@lists.freedesktop.org">fribidi@lists.freedesktop.org</a> <a onclick="return top.js.OpenExtLink(window,event,this)" href="http://lists.freedesktop.org/mailman/listinfo/fribidi" target="_blank">http://lists.freedesktop.org/mailman/listinfo/fribidi</a> </blockquote></div>