Please review fix for 6705913 "freetype_versioncheck.exe - Unable To Locate Component"

Kelly O'Hair Kelly.Ohair at Sun.COM
Fri Aug 21 20:49:03 UTC 2009



Martin Buchholz wrote:
> A way to check at runtime, since freetype 2.0.9, is
> 
>     - A  new function  named  `FT_Library_Version' has  been added  to
>       return  the current  library's major,  minor, and  patch version
>       numbers.   This is  important since  the  macros FREETYPE_MAJOR,
>       FREETYPE_MINOR,  and  FREETYPE_PATCH  cannot  be used  when  the
>       library is dynamically linked by a program.
> 
> So it is possible to have compile-time, link-time,
> and run-time library versions checked.
> 
> ---
> 
> BTW, I just can't believe that building a simple program
> with recent microsoft compilers can be so difficult.
> There must be a saner way.

I suspect that developers using Visual Studio IDE, and not using their
own GNU makefiles, and running the cl.exe compiler directly, probably
have saner options.

-kto

> 
> Martin
> 
> 
> On Fri, Aug 21, 2009 at 12:20, Kelly O'Hair <Kelly.Ohair at sun.com 
> <mailto:Kelly.Ohair at sun.com>> wrote:
> 
>     Humm...  as much as building a freetype application tells us that the
>     libraries work, I'm wondering if we could just do something like this
>     in the makefile sanity check:
> 
>     ifdef OPENJDK
>      FREETYPE_VERSION_H=$(FREETYPE_HEADERS_PATH)/freetype/freetype.h
>      _FREETYPE_VER := \
>        if [ -f "${FREETYPE_VERSION_H}" ] ; then \
>          _major="`${GREP} 'define FREETYPE_MAJOR' | ${CUT} -d' ' -f3`" ; \
>          _minor="`${GREP} 'define FREETYPE_MINOR' | ${CUT} -d' ' -f3`" ; \
>          _micro="`${GREP} 'define FREETYPE_PATCH' | ${CUT} -d' ' -f3`" ; \
>          $(ECHO) "${_major}.${_minor}.${_micro}"; \
>        else \
>          $(ECHO) "0.0.0"; \
>        fi
>      FREETYPE_VER :=$(call GetVersion,"$(_FREETYPE_VER)")
>      FREETYPE_CHECK :=$(call
>     CheckVersions,$(FREETYPE_VER),$(REQUIRED_FREETYPE_VERSION))
> 
>     sane-freetype:
>            @if [ "$(FREETYPE_CHECK)" != "same" -a "$(FREETYPE_CHECK)" !=
>     "newer" ]; then \
>              $(ECHO) "ERROR: The version of freetype being used is older
>     than \n" \
>                  "    the required version of
>     '$(REQUIRED_FREETYPE_VERSION)'. \n" \
>                  "    The version of freetype found was
>     '$(FREETYPE_VER)'. \n" \
>                  "" >> $(ERROR_FILE) ; \
>            fi
> 
>     else
> 
>     #do nothing  (not OpenJDK)
>     sane-freetype:
> 
>     endif
> 
> 
>     ---
>     Just a thought.... Then that whole freetype check program can go away,
>     but if the libraries are wrong, we won't find out at sanity check time.
> 
>     (I have not tested the above logic)
> 
>     -kto
> 
> 
>     Tim Bell wrote:
> 
>         Kelly O'Hair wrote:
> 
>             Looks good Tim.
> 
> 
>         Thanks, Kelly.  I plan to push this fix to the build forest
>         later today.
> 
>             I wish that freetype just had a simple version.h file we
>             could check. :^(
> 
> 
>         I checked the freetype 2.3.5 include files... we could use this from
>         include/freetype/freetype.h:
> 
>          /*************************************************************************
>           *
>           *  @enum:
>           *    FREETYPE_XXX
>           *
>           *  @description:
>           *    These three macros identify the FreeType source code version.
>           *    Use @FT_Library_Version to access them at runtime.
>           *
>           *  @values:
>           *    FREETYPE_MAJOR :: The major version number.
>           *    FREETYPE_MINOR :: The minor version number.
>           *    FREETYPE_PATCH :: The patch level.
>           *
>           *  @note:
>           *    The version number of FreeType if built as a dynamic link
>         library
>           *    with the `libtool' package is _not_ controlled by these three
>           *    macros.
>           */
>         #define FREETYPE_MAJOR  2
>         #define FREETYPE_MINOR  3
>         #define FREETYPE_PATCH  5
> 
> 
> 
>         Tim
> 
>             -kto
> 
>             Tim Bell wrote:
> 
>                 Hi Folks
> 
>                 When building OpenJDK, the freetype sanity check compiles a
>                 little program to test that the freetype include files and
>                 libraries are available, and also that the version number is
>                 acceptable.
> 
>                 If building on Windows and using a Visual Studio compiler
>                 newer than 2003, this program will fail due to the new
>                 rules for accessing MSVCR??.dll. [1]
> 
>                 I didn't make the up the rules, in fact I am extremely
>                 puzzled that Microsoft is forcing ALL external developers
>                 and ISVs to solve this problem.  I am trying to get the
>                 OpenJDK build to deal with them or at least tolerate
>                 them for those people out there who build OpenJDK on
>                 Windows.
> 
>                 The bugzilla report:
>                  https://bugs.openjdk.java.net/show_bug.cgi?id=100101
> 
>                 The code review:
>                  http://cr.openjdk.java.net/~tbell/6705913/webrev.00/
>                 <http://cr.openjdk.java.net/%7Etbell/6705913/webrev.00/>
> 
>                 These changes build OK on all JPRT systems:
> 
>                 linux_i586_2.6
>                 linux_x64_2.6
>                 solaris_i586_5.10
>                 solaris_sparc_5.10
>                 solaris_sparcv9_5.10
>                 solaris_x64_5.10-
>                 windows_i586_5.0
>                 windows_x64_5.2
> 
>                 They also work on my Windows XP SP2 / Visual Studio 2008
>                 build machine.
> 
>                 Thanks in advance-
> 
>                 Tim
> 
>                 [1] How to redistribute the Visual C++ Libraries with
>                 your application (Ben Anderson)
>                 http://blogs.msdn.com/vcblog/archive/2007/10/12/how-to-redistribute-the-visual-c-libraries-with-your-application.aspx
> 
> 
> 



More information about the build-dev mailing list