Please review fix for 6705913 "freetype_versioncheck.exe - Unable To Locate Component"
Igor Nekrestyanov
Igor.Nekrestyanov at Sun.COM
Fri Aug 21 20:28:11 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.
This is exactly the reason to compile freetype_versioncheck (it uses
FT_Library_Version).
We wanted to check that both headers and library are ok.
We can consider relaxing sanity check but it may end up in weird build
failures later on if there are multiple versions of freetype on the platform
or if library was manually compiled and it is not ok. We had these
issues in the past but might be older (incompatible) versions of freetype
are not very widely used anymore.
> 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.
Agree. This seems very odd.
Don't we have to have same workaround to all other exe files?
If we absolutely need to have this then why it is not shared between all
other places?
-igor
>
> 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