1213186 - building against freetype-2.6.1 fails

Status: RESOLVED DUPLICATE of bug 1194520

(Core :: Graphics: Color Management, defect)

Description

[gabriele balducci]

User Agent: Mozilla/5.0 (Windows NT 6.1; rv:31.0) Gecko/20100101 Firefox/31.0
Build ID: Gecko/20100101

Steps to reproduce:

build firefox-42.0b4 from source vs freetype-2.6.1 (current stable)


Actual results:

build fails with:
    --8<----8<----8<----8<-- 
        ../../gfx/skia/SkFontHost_FreeType.o: In function `SkTypeface_FreeType::onGetAdvancedTypefaceMetrics(SkAdvancedTypefaceMetrics::PerGlyphInfo, unsigned int const*, unsigned int) const':
        /home/balducci/tmp/install-us-d/firefox-42.0b3.d/firefox-42.0b4/gfx/skia/skia/src/ports/SkFontHost_FreeType.cpp:560: undefined reference to `FT_Get_X11_Font_Format'
        collect2: error: ld returned 1 exit status
        /home/balducci/tmp/install-us-d/firefox-42.0b3.d/firefox-42.0b4/config/rules.mk:826: recipe for target 'libxul.so' failed
        make[4]: *** [libxul.so] Error 1
        make[4]: Leaving directory '/home/balducci/tmp/install-us-d/firefox-42.0b3.d/firefox-42.0b4/obj-dir/toolkit/library'
    --8<----8<----8<----8<--



Expected results:

build should have completed without errors :]

    This  is the  same as  #1143411, which has worked up to (and including) freetype-2.6.
    But  freetype-2.6 and  freetype-2.6.1
    install headers in different places:

      freetype-2.6:   /usr/include/freetype2
      freetype-2.6.1: /usr/include/freetype2/freetype

    So, not   only   ftfntfmt.h    (fixed   in   #1143411),   but   also
    freetype/ftfntfmt.h needs to be added  to the list of freetype headers
    in config/system-headers

    As a matter of fact, this fixes everything for me:

    diff -c config/system-headers.FIX_SYSTEM_HEADERS config/system-headers
    *** config/system-headers.FIX_SYSTEM_HEADERS	Thu Oct  8 18:29:42 2015
    --- config/system-headers	Thu Oct  8 18:29:42 2015
    ***************
    *** 455,460 ****
    --- 455,461 ----
      frame/req.h
      freetype/freetype.h
      freetype/ftcache.h
    + freetype/ftfntfmt.h
      freetype/ftglyph.h
      freetype/ftsynth.h
      freetype/ftoutln.h

Comment 1

[Argy Megalios]

I'm having the same issue (build fails with freetype 2.6.1), on Arch Linux x86_64, however I get different error messages and although the error has to do with the same function (`FT_Get_X11_Font_Format') the proposed patch doesn't solve it.

I get a load of warnings just like the first one below about many different functions, and then:

../../build/unix/gold/ld: warning: hidden symbol 'FT_Get_X11_Font_Format' in /usr/lib/libfreetype.so is referenced by DSO /usr/lib/libcairo.so
../../build/unix/gold/ld: error: /home/argy/kerncomp/firefox/src/firefox-42.0b5/obj-x86_64-unknown-linux-gnu/toolkit/library/../../gfx/skia/SkFontHost_FreeType.i_o: requires dynamic R_X86_64_PC32 reloc against 'FT_Get_X11_Font_Format' which may overflow at runtime; recompile with -fPIC
../../build/unix/gold/ld: error: read-only segment has dynamic relocations
../../build/unix/gold/ld: error: hidden symbol 'FT_Get_X11_Font_Format' is not defined locally
collect2: error: ld returned 1 exit status
/home/argy/kerncomp/firefox/src/firefox-42.0b5/config/rules.mk:826: recipe for target 'libxul.so' failed
make[6]: *** [libxul.so] Error 1

Comment 2

[gabriele balducci]

Argyris,

I don't think this is related with my report. The fix I mention does solve everything for me and firefox builds without problems after applying it.

Rather, it looks like your freetype wasn't built with -fPIC.
If this is the case, good chances are that building with -fPIC will make those errors go away.

Comment 3

[Argy Megalios]

True, my bad, it had something to do with my setup (though it wasn't the freetype build), anyway after building in a clean chroot I can confirm the patch solves the issue.

Comment 4

[Argy Megalios]

I think there may have been a misunderstanding. My -fPIC errors were irrelevant but the bug itself is not invalid. The patch proposed above is indeed necessary to build against freetype-2.6.1.

Comment 5

[Dirkjan Ochtman (:djc)]

Ah, sorry about that. It looks like this is a duplicate of bug 1194520, then?

Comment 6

[gabriele balducci]

definitely yes!
(I didn't catch that one)