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@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.bur...@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 >
