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 <[email protected]
<mailto:[email protected]>> 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
