Compilation for Windows environment

[Christophe Gisquet]

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

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

--- bin/fribidi-benchmark.c.old Tue Apr  8 17:13:03 2008
+++ bin/fribidi-benchmark.c Tue Apr  8 17:22:43 2008
@@ -123,10 +123,16 @@
   void
 )
 {
-  struct tms tb;
 #if HAVE_SYS_TIMES_H+0
+  struct tms tb;
   times (&tb);
   return 0.01 * tb.tms_utime;
+#elif defined(_WIN32)
+  /* http://msdn2.microsoft.com/en-us/library/4e2ess30(VS.80).aspxi
+   * The diviser should be 1/CLOCKS_PER_SEC, but as it is forced as 0.01
+   * above, let's be consistent.
+   */
+  return 0.01*clock();
 #else
 #warning Please fill in here to use other functions for determining time.
 #endif


_______________________________________________
fribidi mailing list
fribidi@...
http://lists.freedesktop.org/mailman/listinfo/fribidi

[Dov Grobgeld-2]

Some parts of this message have been removed. Learn more about Nabble's security policy.

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

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@...
http://lists.freedesktop.org/mailman/listinfo/fribidi

_______________________________________________
fribidi mailing list
fribidi@...
http://lists.freedesktop.org/mailman/listinfo/fribidi

[Christophe Gisquet]

Hi,

Dov Grobgeld a écrit :
> 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.

Fortunately, my program is under the GPL (and even more, as the data is
also licensed under the GPL):
http://www.wormux.org

And I'm contributing this because it would have been a pity to waste
this work (at least upstream).

Best regards,
Christophe GISQUET
_______________________________________________
fribidi mailing list
fribidi@...
http://lists.freedesktop.org/mailman/listinfo/fribidi

[Shachar Shemesh-12]

Dov Grobgeld wrote:

> 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.
No, that is a misrepresentation of the license, actually. If he compiled
it statically, he has to provide the OBJECT output to anyone interested.
I.e. - the program compiled but not yet linked. There is no requirement
to provide sources.

Shachar
_______________________________________________
fribidi mailing list
fribidi@...
http://lists.freedesktop.org/mailman/listinfo/fribidi