RFR: JDK-8001922, JDK-8001927, JDK-8001921 Improve freetype detection

[Mike Duigou]

The freetype detection on Ubuntu 13.10 x64 appears to be broken as a result of this changeset.

configure:31851: checking for freetype
configure:31853: result: yes (using pkg-config)
configure:34239: checking if we can compile and link with freetype
configure:34264:  /usr/bin/g++-4.8 -o conftest  -I/usr/include/freetype2     -lfreetype conftest.cpp  >&5
/tmp/ccfUxhRh.o: In function `main':
conftest.cpp:(.text+0xa): undefined reference to `FT_Init_FreeType'
collect2: error: ld returned 1 exit status
configure:34264: $? = 1
configure: failed program was:
| /* confdefs.h */
| #define PACKAGE_NAME "OpenJDK"
| #define PACKAGE_TARNAME "openjdk"
| #define PACKAGE_VERSION "jdk8"
| #define PACKAGE_STRING "OpenJDK jdk8"
| #define PACKAGE_BUGREPORT "build-dev at openjdk.java.net"
| #define PACKAGE_URL "http://openjdk.java.net"
| #define STDC_HEADERS 1
| #define HAVE_SYS_TYPES_H 1
| #define HAVE_SYS_STAT_H 1
| #define HAVE_STDLIB_H 1
| #define HAVE_STRING_H 1
| #define HAVE_MEMORY_H 1
| #define HAVE_STRINGS_H 1
| #define HAVE_INTTYPES_H 1
| #define HAVE_STDINT_H 1
| #define HAVE_UNISTD_H 1
| #define HAVE_STDIO_H 1
| #define SIZEOF_INT_P 8
| #define HAVE_X11_EXTENSIONS_SHAPE_H 1
| #define HAVE_X11_EXTENSIONS_XRENDER_H 1
| #define HAVE_X11_EXTENSIONS_XTEST_H 1
| #define HAVE_X11_INTRINSIC_H 1
| #define HAVE_CUPS_CUPS_H 1
| #define HAVE_CUPS_PPD_H 1
| /* end confdefs.h.  */
| 
|           #include<ft2build.h>
|           #include FT_FREETYPE_H
|           int main () {
|             FT_Init_FreeType(NULL);
|             return 0;
|           }
| 
configure:34271: result: no
configure:34273: Could not compile and link with freetype. This might be a 32/64-bit mismatch.
configure:34275: Using FREETYPE_CFLAGS=-I/usr/include/freetype2   and FREETYPE_LIBS=-lfreetype
configure:34311: error: Can not continue without freetype. You might be able to fix this by running 'sudo apt-get install libfreetype6-dev'.




On Oct 23 2013, at 00:52 , Magnus Ihse Bursie <magnus.ihse.bursie at oracle.com> wrote:

> On 2013-10-21 15:38, Magnus Ihse Bursie wrote:
>> 
>>> A question on Windows. If we find freetype in $PROGRAMFILES/GnuWin32, will the resulting jdk image find the library there at runtime or should we still bundle it?
>> [...]
>> 
>> *) Actually, when I scrutinized the code, I noticed that USING_SYSTEM_FT_LIB was incorrectly set when using builddeps or pkg-config. I'll update the WebRe regarding this and the typo.
>> 
> 
> This fix has grown a bit. I've published a new webrev. Some comments about the changes since the last webrev: The old logic with USING_SYSTEM_FT_LIB was very hard to follow, and arguably completely     wrong in certain situations. Instead of trying harder to adapt the configure code to the existing makefile logic, I decided to fix the makefile logic, and make our behavior more explicit. 
> 
> The explicit behaviour is now that we, by default, bundle the freetype library on Windows, or (on any platform) when using --with-freetype. There is now a new flag, --enable/disable-freetype-bundling, which overrides this behavior,     and forces/prohibits bundling, regardless of circumstances. If we force bundling, but do not specify a freetype library path, we might be unable to use a freetype library that was provided via builddeps or pkg-config. This is now correctly checked for, and this freetype     library is skipped, and we continue search for one that we can bundle.
> 
> I also finally got tired of the mix between using "FREETYPE" and "FREETYPE2", and replaced all instances with just FREETYPE (the versioning is not relevant, and we don't use it for any other library). It's still needed when interfacing external systems such as pkg-config, though.
> 
> Finally, it turned out that we do indeed require freetype to build on macosx, contrary to the apparent look of the code, and contrary to general build instructions. :-) We just sneakily detected freetype, and if it were not there, we could not build successfully on macosx. (This is for the open part only; the closed build does not require freetype). I'm not sure if this is a documentation bug, or a build system bug. In any case; I've restored the previous behavior, and made it more explicit. If this behavior should be changed, it must be covered in another bug.
> 
> Updated webrev: http://cr.openjdk.java.net/~ihse/JDK-8001922-improve-freetype-detection/webrev.03
> 
> /Magnus
>