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

Martin Buchholz martinrb at google.com
Fri Aug 21 20:06:50 UTC 2009


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.

Martin


On Fri, Aug 21, 2009 at 12:20, Kelly O'Hair <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
>>>>
>>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/build-dev/attachments/20090821/528bba50/attachment.html>


More information about the build-dev mailing list