[FriBidi] Compilation for Windows environment

[Dov Grobgeld]

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

On 08/04/2008, Christophe GISQUET <christophe.gisquet at free.fr> wrote:
>
> 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:
> http://msdn2.microsoft.com/en-us/library/8fskxacy(VS.80).aspx<http://msdn2.microsoft.com/en-us/library/8fskxacy%28VS.80%29.aspx>
>
> 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
> fribidi at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/fribidi
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.freedesktop.org/archives/fribidi/attachments/20080408/2cd8dc92/attachment.htm