Hello!

This updated package seems to have at least one problem: It runs configure 
twice.

The reason is that it starts the build with a PatchScript that starts with

        ./autogen.sh

which has as its last line

        $srcdir/configure "$@"

So when it has finished it invokes configure without any arguments and options. 
*Then* follows patching of files – and one of these files is autogen.sh. This 
patch comes to late. It changes the last line to

        #$srcdir/configure "$@"

(This patch is also the last one in openmotif4.patch.) Then follows the 
invocation of ./configure with arguments. openmotif4.info should be changed from

          ./autogen.sh
          patch -p1 < %{PatchFile}
          perl -pi.bak -e 's,-flat_namespace -undefined suppress,-undefined 
dynamic_lookup,g' configure
          ...

to at least

          patch -p1 < %{PatchFile}
          ./autogen.sh
          perl -pi.bak -e 's,-flat_namespace -undefined suppress,-undefined 
dynamic_lookup,g' configure
          ...

(or making ./autogen.sh the last statement of the PatchScript?)


The final configure step shows some problematic results:

        checking for XpCreateContext in -lXp... yes
        checking for freetype-config... freetype-config
        checking freetype/freetype.h usability... no
        checking freetype/freetype.h presence... no
        checking for freetype/freetype.h... no
        checking X11/extensions/Xrender.h usability... yes
        checking X11/extensions/Xrender.h presence... yes
        checking for X11/extensions/Xrender.h... yes
        checking for XRenderParseColor... yes
        checking for fontconfig-config... no
        checking fontconfig/fontconfig.h usability... yes
        checking fontconfig/fontconfig.h presence... yes
        checking for fontconfig/fontconfig.h... yes
        checking for FcInit... no
        checking jpeglib.h usability... yes
        checking jpeglib.h presence... no
        configure: WARNING: jpeglib.h: accepted by the compiler, rejected by 
the preprocessor!
        configure: WARNING: jpeglib.h: proceeding with the compiler's result
        checking for jpeglib.h... yes
        checking for jpeg_start_decompress… yes

The problem with freetype/freetype.h is quite clear. The test programme in 
configure still seems to be tailored for Freetype version 1: It does not start 
with

        #include <ft2build.h>
        #include FT_FREETYPE_H

and so GCC reports:

        In file included from conftest.c:115:
        /sw/include/freetype2/freetype/freetype.h:24:2: error: #error 
"`ft2build.h' hasn't been included yet!"
        /sw/include/freetype2/freetype/freetype.h:25:2: error: #error "Please 
always use macros to include FreeType header files."
        /sw/include/freetype2/freetype/freetype.h:26:2: error: #error "Example:"
        /sw/include/freetype2/freetype/freetype.h:27:2: error: #error "  
#include <ft2build.h>"
        /sw/include/freetype2/freetype/freetype.h:28:2: error: #error "  
#include FT_FREETYPE_H"

Similarly the failure with FcInit is due to expecting something different than 
the present state of software. The compiler invocation is:

        gcc -o conftest -I/sw/include -I/usr/X11R6/include 
-DXNO_MTSAFE_STRINGAPI -DXNO_MTSAFE_PWDAPI -DXNO_MTSAFE_TIMEAPI -H -Wall -g 
-fno-strict-aliasing -Wno-unused -Wno-comment -fno-tree-ter -H 
-I/usr/X11R6/include -L/sw/lib -L/usr/X11R6/lib -t -L/sw/lib conftest.c -lXp 
-liconv -L/sw/lib -L/usr/X11R6/lib -lXt -L/usr/X11R6/lib -lXft -lXrender

and does not contain -lfontconfig.

The test for "jpeglib.h presence" might need a patch, because it is a bit too 
simple:

        configure:15675: checking jpeglib.h presence
        configure:15675: gcc -E -H -I/usr/X11R6/include conftest.c
        conftest.c:89:21: error: jpeglib.h: No such file or directory


Tried on 32-bit Mac OS X 10.6.8, Snow Leopard.


Maybe I'm wrong and OpenMotif cannot use FreeType 2 and libfontconfig at all…

--
Greetings

  Pete

Remember, "Advance too fast, you catch up with death. But advance too slow, 
death catches up with *you*."




------------------------------------------------------------------------------
Android is increasing in popularity, but the open development platform that
developers love is also attractive to malware creators. Download this white
paper to learn more about secure code signing practices that can help keep
Android apps secure.
http://pubads.g.doubleclick.net/gampad/clk?id=65839951&iu=/4140/ostg.clktrk
_______________________________________________
Fink-users mailing list
Fink-users@lists.sourceforge.net
List archive:
http://news.gmane.org/gmane.os.macosx.fink.user
Subscription management:
https://lists.sourceforge.net/lists/listinfo/fink-users

Reply via email to