986008 - undefined png-related symbols when building freetype for Android

Status: RESOLVED DUPLICATE of bug 985806

(Firefox Build System :: General, defect)

Description

[Brad Lassey [:blassey] (use needinfo?)]

19:55.09 /Volumes/source/mozilla-central/modules/freetype2/src/autofit/afglobal.c:326: error: undefined reference to 'hb_ft_font_create'
19:55.09 /Volumes/source/mozilla-central/modules/freetype2/src/sfnt/pngshim.c:125: error: undefined reference to 'png_get_error_ptr'
19:55.09 /Volumes/source/mozilla-central/modules/freetype2/src/sfnt/pngshim.c:132: error: undefined reference to 'png_set_longjmp_fn'
19:55.09 /Volumes/source/mozilla-central/modules/freetype2/src/sfnt/pngshim.c:156: error: undefined reference to 'png_get_io_ptr'
19:55.10 /Volumes/source/mozilla-central/modules/freetype2/src/sfnt/pngshim.c:162: error: undefined reference to 'png_get_error_ptr'
19:55.10 /Volumes/source/mozilla-central/modules/freetype2/src/sfnt/pngshim.c:166: error: undefined reference to 'png_error'
19:55.10 /Volumes/source/mozilla-central/modules/freetype2/src/sfnt/pngshim.c:220: error: undefined reference to 'png_create_read_struct'
19:55.10 /Volumes/source/mozilla-central/modules/freetype2/src/sfnt/pngshim.c:230: error: undefined reference to 'png_create_info_struct'
19:55.10 /Volumes/source/mozilla-central/modules/freetype2/src/sfnt/pngshim.c:234: error: undefined reference to 'png_destroy_read_struct'
19:55.10 /Volumes/source/mozilla-central/modules/freetype2/src/sfnt/pngshim.c:238: error: undefined reference to 'png_set_longjmp_fn'
19:55.10 /Volumes/source/mozilla-central/modules/freetype2/src/sfnt/pngshim.c:244: error: undefined reference to 'png_set_read_fn'
19:55.10 /Volumes/source/mozilla-central/modules/freetype2/src/sfnt/pngshim.c:246: error: undefined reference to 'png_read_info'
19:55.10 /Volumes/source/mozilla-central/modules/freetype2/src/sfnt/pngshim.c:247: error: undefined reference to 'png_get_IHDR'
19:55.10 /Volumes/source/mozilla-central/modules/freetype2/src/sfnt/pngshim.c:281: error: undefined reference to 'png_set_palette_to_rgb'
19:55.10 /Volumes/source/mozilla-central/modules/freetype2/src/sfnt/pngshim.c:287: error: undefined reference to 'png_set_expand_gray_1_2_4_to_8'
19:55.10 /Volumes/source/mozilla-central/modules/freetype2/src/sfnt/pngshim.c:294: error: undefined reference to 'png_get_valid'
19:55.10 /Volumes/source/mozilla-central/modules/freetype2/src/sfnt/pngshim.c:295: error: undefined reference to 'png_set_tRNS_to_alpha'
19:55.10 /Volumes/source/mozilla-central/modules/freetype2/src/sfnt/pngshim.c:298: error: undefined reference to 'png_set_strip_16'
19:55.10 /Volumes/source/mozilla-central/modules/freetype2/src/sfnt/pngshim.c:301: error: undefined reference to 'png_set_packing'
19:55.10 /Volumes/source/mozilla-central/modules/freetype2/src/sfnt/pngshim.c:306: error: undefined reference to 'png_set_gray_to_rgb'
19:55.10 /Volumes/source/mozilla-central/modules/freetype2/src/sfnt/pngshim.c:309: error: undefined reference to 'png_set_interlace_handling'
19:55.10 /Volumes/source/mozilla-central/modules/freetype2/src/sfnt/pngshim.c:311: error: undefined reference to 'png_set_filler'
19:55.10 /Volumes/source/mozilla-central/modules/freetype2/src/sfnt/pngshim.c:314: error: undefined reference to 'png_read_update_info'
19:55.10 /Volumes/source/mozilla-central/modules/freetype2/src/sfnt/pngshim.c:315: error: undefined reference to 'png_get_IHDR'
19:55.10 /Volumes/source/mozilla-central/modules/freetype2/src/sfnt/pngshim.c:334: error: undefined reference to 'png_set_read_user_transform_fn'
19:55.10 /Volumes/source/mozilla-central/modules/freetype2/src/sfnt/pngshim.c:339: error: undefined reference to 'png_set_read_user_transform_fn'
19:55.10 /Volumes/source/mozilla-central/modules/freetype2/src/sfnt/pngshim.c:352: error: undefined reference to 'png_read_image'
19:55.10 /Volumes/source/mozilla-central/modules/freetype2/src/sfnt/pngshim.c:356: error: undefined reference to 'png_read_end'
19:55.10 /Volumes/source/mozilla-central/modules/freetype2/src/sfnt/pngshim.c:359: error: undefined reference to 'png_destroy_read_struct'
19:55.10 collect2: error: ld returned 1 exit status
19:55.10 make[5]: *** [libxul.so] Error 1
19:55.10 make[4]: *** [toolkit/library/libs] Error 2
19:55.10 make[3]: *** [libs] Error 2
19:55.10 make[2]: *** [default] Error 2
19:55.10 make[1]: *** [realbuild] Error 2
19:55.10 make: *** [build] Error 2
19:55.11 658 compiler warnings present.

I assume this is a regression from bug 969814

Comment 1

[Jonathan Kew [:jfkthame]]

I've also just run into this on my local Android build. I believe it's actually triggered by the freetype update in bug 981435. Prior to that, it was building fine.

Comment 2

[Michael Wu [:mwu]]

Bug 985803 will fix at least one of these undefined references.

Comment 3

[Jonathan Kew [:jfkthame]]

I've just noticed that those undefined references are showing png_* symbols rather than the MOZ_PNG_* versions that we rename them to in mozpngconf.h.

This suggests that the freetype compilation is not picking up our libpng configuration, but rather one from the host system.

Comment 4

[Brad Lassey [:blassey] (use needinfo?)]

You're right, the freetype update did cause this

Comment 5

[Jonathan Kew [:jfkthame]]

During the freetype compilation:

 2:09.30 libtool: compile:  /Users/jkew/android-ndk-r8e/toolchains/arm-linux-androideabi-4.7/prebuilt/darwin-x86_64/bin/arm-linux-androideabi-gcc -pedantic -ansi -idirafter /Users/jkew/android-ndk-r8e/platforms/android-9/arch-arm/usr/include -g -I/Users/jkew/mozdev/mc-clean/obj-arm-linux-androideabi/modules/freetype2 -I/Users/jkew/mozdev/mc-clean/modules/freetype2/builds/unix -I/Users/jkew/mozdev/mc-clean/modules/freetype2/include -c -Wall -Wall -Wpointer-arith -Wdeclaration-after-statement -Werror=return-type -Werror=int-to-pointer-cast -Wtype-limits -Wempty-body -Wsign-compare -Wno-unused -Wno-error=uninitialized -Wno-error=maybe-uninitialized -Wno-error=deprecated-declarations -mandroid -fno-short-enums -fno-exceptions -march=armv7-a -mthumb -mfpu=vfp -mfloat-abi=softfp -mno-unaligned-access -std=gnu99 -fgnu89-inline -fno-strict-aliasing -ffunction-sections -fdata-sections -fno-math-errno -pipe -g -std=c99 -I/opt/local/include -DFT_CONFIG_OPTION_SYSTEM_ZLIB -I/Users/jkew/mozdev/mc-clean/obj-arm-linux-androideabi/dist/include -DFT_CONFIG_OPTION_USE_PNG "-DFT_CONFIG_CONFIG_H=<ftconfig.h>" -DFT2_BUILD_LIBRARY "-DFT_CONFIG_MODULES_H=<ftmodule.h>" -I/Users/jkew/mozdev/mc-clean/modules/freetype2/src/sfnt /Users/jkew/mozdev/mc-clean/modules/freetype2/src/sfnt/sfnt.c  -fPIC -DPIC -o /Users/jkew/mozdev/mc-clean/obj-arm-linux-androideabi/modules/freetype2/sfnt.o

I don't see the expected path from $MOZ_PNG_CFLAGS there, which is why it's missing our configuration and compiling against the system one. But then we don't actually link against the system libpng (which is good - we don't want to be linking with two versions of it), and so the un-renamed symbols are undefined.

Comment 6

[Jonathan Kew [:jfkthame]]

Uh, correction... the path from MOZ_PNG_CFLAGS would be $objdir/dist/include, which is present here. I guess the trouble is probably that a path to system libpng headers is taking precedence over it.

Comment 7

[Jonathan Kew [:jfkthame]]

OK, so what's happening (at least in my case) is that the freetype compilation step is seeing the libpng headers from my local MacPorts installation, and these are taking precedence over our in-tree libpng headers. :(

So I can work around the failure by removing libpng from MacPorts ... but that's pretty painful, as I have a bunch of other stuff that depends on it.

Comment 8

[Jonathan Kew [:jfkthame]]

And it turns out the culprit is zlib ... inasmuch as the freetype configure script is finding my MacPorts-installed zlib in /opt/local, which is why we get -I/opt/local/include in the compile command. And that in turn means the MacPorts-installed libpng shadows the in-tree one that we're trying to use, and we get the wrong symbol names.

Even if it weren't for the symbol-renaming problem, there'd be the risk of version mismatches between the "system" header we're finding during the freetype compilation and the objects from the in-tree version that we actually link.

It also seems wrong to me that the (freetype) build is finding my MacPorts version of zlib when cross-compiling for Android; it's only using the header from there, and then we actually link to the real android lib, but this is fundamentally broken; the only reason we're getting away with it is that zlib is stable enough that the two do actually match.

I think what we really need to do is to ensure that -no- host headers/libraries are used by the freetype build. It should be using either the target system ones from the android SDK, or our in-tree versions, but never the host system's libs.

A possible workaround is to add
  --with-zlib=no
to the freetype configure command we run, to prevent it looking for a "system" library.

Comment 9

[Brad Lassey [:blassey] (use needinfo?)]

I think part of the problem is with the configure script. If you have LIBPNG_CFLAGS/LIBS set, its supposed to use them. But, have_libpng gets initialized to "no"[1] and then get's tested for != "no" [2], the else block of which calls libpng-config. I suspect that [3] is the bug, where it tests LIBPNG_CFLAGS and LIBPNG_LIBS and then sets have_libpng_pkg to "yes"

[1] http://mxr.mozilla.org/mozilla-central/source/modules/freetype2/builds/unix/configure#12865
[2] http://mxr.mozilla.org/mozilla-central/source/modules/freetype2/builds/unix/configure#12960
[3] http://mxr.mozilla.org/mozilla-central/source/modules/freetype2/builds/unix/configure#12877

Comment 10

[Mike Hommey [:glandium]]

Comment 8 makes this a dupe of bug 985806

Comment 11

[Brad Lassey [:blassey] (use needinfo?)]

The patch on bug 985806 doesn't fix this

Comment 12

[Brad Lassey [:blassey] (use needinfo?)]

Attachment: test_flags.patch

This tests for the flags we pass in. I added a space to the ZLIB_CLFAGS because otherwise it's empty and the test doesn't pass.

Comment 13

[Brad Lassey [:blassey] (use needinfo?)]

Also this applies over the patch on bug 985806

Comment 14

[Mike Hommey [:glandium]]

The patch in bug 985806 is not even reviewed yet. The configure.in change can go there directly (and i would have caught it in review). The freetype configure change is not required. PKG_CHECK_MODULES actually considers the test to pass when _CFLAGS and _LIBS values are non empty.

Comment 15

[sheldon.els]

I'm bumping into a similar issue on my first try building Firefox for Android on OSX. Does the duplicate mark here and the resolution of bug 985806 mean I shouldn't be getting this error?