Re: FriBidi Installation

> Date: Sun, 23 Dec 2012 05:58:20 +0200
> From: Eli Zaretskii <[email protected]>
> Cc: [email protected], [email protected]
> 
> > Date: Sat, 22 Dec 2012 20:35:03 -0500
> > From: Behdad Esfahbod <[email protected]>
> > Cc: FriBidi <[email protected]>
> > 
> > There's not really much I can help you with.  You need a build environment set
> > up first.  There's nothing FriBidi specific to that.  It's a Windows issues.
> > Then you can compile FriBidi.
> 
> Just installing MSYS+MinGW should be all that's needed.  Then you just
> do the usual Unix stance: "configure && make"

I spoke too soon, there are a few obstacles on the way.  Here's my
report of building fribidi-0.19.5 on MS-Windows using MSYS+MinGW32:

 . Compilation warnings:

       CC     fribidi-char-sets.lo
     fribidi-char-sets.c:121:1: warning: conflicting types for built-in function 'toupper' [enabled by default]

   This happens because charset/fribidi-char-sets.c defines its own
   'static' function toupper.  Solution -- rename it to fribidi_toupper.
   I think it's not nice for a project to invade the namespace of the
   standard C library.

       CC     fribidi-bidi-types.lo
     In file included from fribidi-bidi-types.c:93:0:
     fribidi-bidi-types.c: In function 'fribidi_get_bidi_type_name':
     fribidi-bidi-types-list.h:83:1: warning: case value '32' not in enumerated type 'FriBidiCharType' [-Wswitch]
     fribidi-bidi-types-list.h:84:1: warning: case value '33' not in enumerated type 'FriBidiCharType' [-Wswitch]
     In file included from fribidi-bidi-types.c:113:0:
     fribidi-bidi-types.c: In function '_fribidi__char_from_bidi_type__internal__':
     fribidi-bidi-types-list.h:83:1: warning: case value '32' not in enumerated type 'FriBidiCharType' [-Wswitch]
     fribidi-bidi-types-list.h:84:1: warning: case value '33' not in enumerated type 'FriBidiCharType' [-Wswitch]

   I didn't figure out how to fix those, as the complex system of
   macros used by fribidi-bidi-types-list.h is, well, complex.  Any
   suggestions?

 . Fatal error during linking:

     /bin/sh ../libtool  --tag=CC   --mode=link gcc  -g -O2 -Wall -ansi  -no-undefined -version-info 3:4:3 -export-symbols-regex "^fribidi_.*" -export-symbols ./fribidi.def  -o libfribidi.la -rpath d:/usr/lib fribidi.lo fribidi-arabic.lo fribidi-bidi.lo fribidi-bidi-types.lo fribidi-deprecated.lo fribidi-joining.lo fribidi-joining-types.lo fribidi-mem.lo fribidi-mirroring.lo fribidi-run.lo fribidi-shape.lo  ../charset/libfribidi-char-sets.la
     libtool: link: more than one -exported-symbols argument is not allowed

   This is because of this test in libtool:

      case $arg in
      [...]
      -export-symbols | -export-symbols-regex)
        if test -n "$export_symbols" || test -n "$export_symbols_regex"; then
          func_fatal_error "more than one -exported-symbols argument is not allowed"
        fi

   It is caused by lib/Makefile.in doing this:

     @OS_WIN32_TRUE@am__append_1 = -export-symbols $(srcdir)/fribidi.def
     ...
     libfribidi_la_LDFLAGS = -no-undefined -version-info $(LT_VERSION_INFO) \
	     -export-symbols-regex "^fribidi_.*" $(am__append_1)

   I solved this by commenting out the am__append_1 line.  Then the
   library was built, and "make check" passed all tests.

   Why is the Windows-specific fribidi.def file needed?  Did libtool
   or Binutils in some old version not support -export-symbols-regex
   on Windows?  If so, that reason is long gone, and you could simply
   use the normal Unix switches to libtool.

Thanks.