Uploaded image for project: 'ROOT'
  1. ROOT
  2. ROOT-5773

include/TTF.h:51:4: error: unknown type name 'FT_Glyph'; did you mean 'FTGlyph'?

    Details

    • Type: Bug
    • Status: Reopened
    • Priority: High
    • Resolution: Unresolved
    • Affects Version/s: 5.34/00
    • Fix Version/s: None
    • Component/s: Build System
    • Environment:

      Mac OS X 10.7, MacPorts, FreeType 2.5.1, ./configure-based build

      Description

      In connection to https://sft.its.cern.ch/jira/browse/ROOT-5767 (even though not really related) I discovered that configure-based build fails for me with

      >/usr/bin/clang++ -v -O2 -m64 -pipe -Wshadow -W -Wall -Woverloaded-virtual -fsigned-char -fno-common -Iinclude -DR__HAVE_CONFIG     -pthread -I/opt/local/include/freetype2 -o graf2d/graf/src/TMathText.o -c /path/to/root/work/root/graf2d/graf/src/TMathText.cxx
      Apple LLVM version 4.2 (clang-425.0.28) (based on LLVM 3.2svn)
      Target: x86_64-apple-darwin11.4.2
      Thread model: posix
       "/usr/bin/clang" -cc1 -triple x86_64-apple-macosx10.7.0 -emit-obj -disable-free -disable-llvm-verifier -main-file-name TMathText.cxx -pic-level 2 -mdisable-fp-elim -masm-verbose -munwind-tables -target-cpu core2 -target-linker-version 136 -v -coverage-file /path/to/root/work/root/graf2d/graf/src/TMathText.o -resource-dir /usr/bin/../lib/clang/4.2 -D R__HAVE_CONFIG -I include -I /opt/local/include/freetype2 -fmodule-cache-path /var/tmp/clang-module-cache -O2 -Wshadow -W -Wall -Woverloaded-virtual -fdeprecated-macro -ferror-limit 19 -fmessage-length 203 -pthread -stack-protector 1 -mstackrealign -fblocks -fobjc-runtime=macosx-10.7.0 -fobjc-dispatch-method=mixed -fobjc-default-synthesize-properties -fcxx-exceptions -fexceptions -fno-common -fdiagnostics-show-option -fcolor-diagnostics -o graf2d/graf/src/TMathText.o -x c++ /path/to/root/work/root/graf2d/graf/src/TMathText.cxx
      clang -cc1 version 4.2 based upon LLVM 3.2svn default target x86_64-apple-darwin11.4.2
      ignoring nonexistent directory "/usr/include/c++/4.2.1/i686-apple-darwin10/x86_64"
      ignoring nonexistent directory "/usr/include/c++/4.0.0"
      ignoring nonexistent directory "/usr/include/c++/4.0.0/i686-apple-darwin8/"
      ignoring nonexistent directory "/usr/include/c++/4.0.0/backward"
      #include "..." search starts here:
      #include <...> search starts here:
       include
       /opt/local/include/freetype2
       /usr/include/c++/4.2.1
       /usr/include/c++/4.2.1/backward
       /usr/local/include
       /usr/bin/../lib/clang/4.2/include
       /usr/include
       /System/Library/Frameworks (framework directory)
       /Library/Frameworks (framework directory)
      End of search list.
      In file included from /path/to/root/work/root/graf2d/graf/src/TMathText.cxx:15:
      include/TTF.h:51:4: error: unknown type name 'FT_Glyph'; did you mean 'FTGlyph'?
         FT_Glyph   fImage; // glyph image
         ^~~~~~~~
         FTGlyph
      include/ftglyph.h:25:19: note: 'FTGlyph' declared here
      class FTGL_EXPORT FTGlyph
                        ^
      In file included from /path/to/root/work/root/graf2d/graf/src/TMathText.cxx:15:
      include/TTF.h:51:15: error: field type 'FTGlyph' is an abstract class
         FT_Glyph   fImage; // glyph image
                    ^
      include/ftglyph.h:49:32: note: unimplemented pure virtual method 'Render' in 'FTGlyph'
              virtual const FTPoint& Render( const FTPoint& pen) = 0;
                                     ^
      2 errors generated.
      

      A few days ago it apparently compiled fine (https://build.macports.org/builders/buildports-lion-x86_64/builds/16074), so this either means that the FreeType upgrade broke the build or that something went wrong on my machine only.

        Activity

        Hide
        matevz Matevz Tadel added a comment -

        Yeah, that was also my first motivation for proposing Rftgl/

        Sorry it took me a while to get involved in this, I'm out of cern for 3+ years now and don't follow root jira for the fun of it anymore ... I had to be bitten by the header removal to actually start sniffing around

        Cheers,
        \m

        Show
        matevz Matevz Tadel added a comment - Yeah, that was also my first motivation for proposing Rftgl/ Sorry it took me a while to get involved in this, I'm out of cern for 3+ years now and don't follow root jira for the fun of it anymore ... I had to be bitten by the header removal to actually start sniffing around Cheers, \m
        Hide
        jonrob Christopher Rob Jones added a comment -

        Please do not remove the ability to use an external version of a library. As a point of principle I think its always better to prefer this when possible, and to avoid the 'monolithic' tendencies root sometimes has, for various reasons. Of course, I understand this requires root to be compatible with the latest versions of these externals, which is not always easy. But I guess eventually this will hit you, unless you propose to stick with a frozen version internal version for ever...

        cheers Chris

        Show
        jonrob Christopher Rob Jones added a comment - Please do not remove the ability to use an external version of a library. As a point of principle I think its always better to prefer this when possible, and to avoid the 'monolithic' tendencies root sometimes has, for various reasons. Of course, I understand this requires root to be compatible with the latest versions of these externals, which is not always easy. But I guess eventually this will hit you, unless you propose to stick with a frozen version internal version for ever... cheers Chris
        Hide
        matevz Matevz Tadel added a comment -

        I wish that was possible, too ... but ftgl was changed significantly between 2.1.2 and what is now 2.1.3-rc (it should be 3.0 given what all has changed). They canned gl state changes into the existing api that just makes it impossible to use. Blender has done the same, too.
        \m

        Show
        matevz Matevz Tadel added a comment - I wish that was possible, too ... but ftgl was changed significantly between 2.1.2 and what is now 2.1.3-rc (it should be 3.0 given what all has changed). They canned gl state changes into the existing api that just makes it impossible to use. Blender has done the same, too. \m
        Hide
        jonrob Christopher Rob Jones added a comment -

        That just means you cannot (at the moment) use an external 2.1.3 build. Nothing stopping you use an external 2.1.2 build though.

        Show
        jonrob Christopher Rob Jones added a comment - That just means you cannot (at the moment) use an external 2.1.3 build. Nothing stopping you use an external 2.1.2 build though.
        Hide
        matevz Matevz Tadel added a comment -

        This was abandoned and we have private changes. Due to what is happening with 2.1.3 there was no point in even trying to get our changes in.

        If you don't care about 3d graphics, you don't have to build it. If you do care about it, you might appreciate that text in OpenGL looks right.

        Show
        matevz Matevz Tadel added a comment - This was abandoned and we have private changes. Due to what is happening with 2.1.3 there was no point in even trying to get our changes in. If you don't care about 3d graphics, you don't have to build it. If you do care about it, you might appreciate that text in OpenGL looks right.

          People

          • Assignee:
            couet Olivier Couet
            Reporter:
            6114858d84b0f40cf715 Mojca Miklavec
          • Votes:
            0 Vote for this issue
            Watchers:
            5 Start watching this issue

            Dates

            • Created:
              Updated: