Opened 7 years ago

Closed 7 years ago

Last modified 7 years ago

#42928 closed defect (invalid)

xft not found when building emacs from source

Reported by: holtzermann17@… Owned by: macports-tickets@…
Priority: Normal Milestone:
Component: ports Version: 2.2.1
Keywords: Cc: jeremyhu (Jeremy Huddleston Sequoia), ryandesign (Ryan Schmidt)
Port: Xft2

Description

I have Xft2 / @2.3.1 installed on OS X 10.9.2. I've tried to build emacs from source, and here's what I see when ./configure runs:

checking for xft >= 0.13.0... yes CFLAGS='-I/opt/local/include -I/opt/local/include/freetype2 -I/opt/local/include -I/opt/local/include/freetype2 -I/opt/local/include ' LIBS='-L/opt/local/lib -lXft '
checking for XRenderQueryExtension in -lXrender... yes
checking for X11/Xft/Xft.h... no
[...]
  Does Emacs use -lxft?                                   no

If this is a problem with Emacs not looking in the right place, I can report this to the Emacs developers, but I want to double check that things are OK on the Macports side first.

Change History (17)

comment:1 in reply to:  description Changed 7 years ago by ryandesign (Ryan Schmidt)

Cc: ryandesign@… added

The Xft2 port looks fine on my system:

$ port -v installed xft2
The following ports are currently installed:
  Xft2 @2.3.1_1+universal (active) platform='darwin 13' archs='i386 x86_64'
$ port contents xft2
Port Xft2 contains:
  /opt/local/include/X11/Xft/Xft.h
  /opt/local/include/X11/Xft/XftCompat.h
  /opt/local/lib/libXft.2.dylib
  /opt/local/lib/libXft.a
  /opt/local/lib/libXft.dylib
  /opt/local/lib/pkgconfig/xft.pc
  /opt/local/share/man/man3/Xft.3.gz

Does building emacs using the emacs port work?

sudo port install emacs +x11

It works for me.

comment:2 Changed 7 years ago by holtzermann17@…

... I wonder if the default port installed version has xft support?

Investigating further (with the help of the Emacs guys), here's a more detailed error from the configure process when I built from source:

In file included from /usr/X11/include/X11/Xft/Xft.h:39:
/usr/X11/include/ft2build.h:56:10: fatal error: 'freetype/config/ftheader.h' file not found
#include <freetype/config/ftheader.h>
         ^
1 error generated.

comment:3 Changed 7 years ago by holtzermann17@…

Hm, interesting...

$ sudo port install freetype
[...]
--->  Activating freetype @2.5.3_1
--->  Cleaning freetype
--->  Updating database of binaries: 100.0%
--->  Scanning binaries for linking errors: 59.2%
Warning: Error parsing file /opt/local/share/ghc-bootstrap/lib/ghc-7.0.4/HSffi.o: Premature end of data, possibly corrupt file
--->  Scanning binaries for linking errors: 100.0%
--->  Found 73 broken file(s), matching files to ports
--->  Found 8 broken port(s), determining rebuild order
--->  Rebuilding in order
     fontconfig @2.11.0 +universal
     cairo @1.12.16 +universal+x11
     harfbuzz @0.9.26 +universal
     Xft2 @2.3.1 +universal
     pango @1.36.2 +universal+x11
     gtk2 @2.24.22 +universal+x11
     gtk3 @3.10.7 +universal+x11
     libcanberra @0.30 +universal+x11
[...]

comment:4 Changed 7 years ago by holtzermann17@…

Changing line 56 of ft2build.h like so fixed it:

*** ft2build.h~	Thu Mar 20 22:13:36 2014
--- ft2build.h	Thu Mar 20 22:13:46 2014
***************
*** 53,59 ****
  #define __FT2_BUILD_UNIX_H__
  
    /* `<prefix>/include/freetype2' must be in your current inclusion path */
! #include <freetype/config/ftheader.h>
  
  #endif /* __FT2_BUILD_UNIX_H__ */
  
--- 53,59 ----
  #define __FT2_BUILD_UNIX_H__
  
    /* `<prefix>/include/freetype2' must be in your current inclusion path */
! #include <freetype2/config/ftheader.h>
  
  #endif /* __FT2_BUILD_UNIX_H__ */

comment:5 in reply to:  2 Changed 7 years ago by ryandesign (Ryan Schmidt)

Replying to holtzermann17@…:

... I wonder if the default port installed version has xft support?

It doesn't.

Investigating further (with the help of the Emacs guys), here's a more detailed error from the configure process when I built from source:

In file included from /usr/X11/include/X11/Xft/Xft.h:39:
/usr/X11/include/ft2build.h:56:10: fatal error: 'freetype/config/ftheader.h' file not found
#include <freetype/config/ftheader.h>
         ^
1 error generated.

That sounds like the problem you'd get with software that is not compatible with freetype 2.5.1 and later.

The diff you proposed is not the correct fix. Consult the freetype documentation for the proper way to include freetype headers.

comment:6 in reply to:  3 Changed 7 years ago by ryandesign (Ryan Schmidt)

Replying to holtzermann17@…:

--->  Found 73 broken file(s), matching files to ports
--->  Found 8 broken port(s), determining rebuild order
--->  Rebuilding in order
     fontconfig @2.11.0 +universal
     cairo @1.12.16 +universal+x11
     harfbuzz @0.9.26 +universal
     Xft2 @2.3.1 +universal
     pango @1.36.2 +universal+x11
     gtk2 @2.24.22 +universal+x11
     gtk3 @3.10.7 +universal+x11
     libcanberra @0.30 +universal+x11
[...]

I wonder why all those ports were considered broken on your system. Did they all rebuild successfully now? Have you run "sudo port upgrade outdated" lately?

comment:7 Changed 7 years ago by holtzermann17@…

They did rebuild successfully - my guess was that they can build without freetype, but when it's present they needed to rebuild for freetype compatibility.

comment:8 Changed 7 years ago by holtzermann17@…

Oh, and I've definitely upgraded within the month, may do it again soon.

comment:9 Changed 7 years ago by ryandesign (Ryan Schmidt)

So where are we with this ticket? Can we close it as invalid? So far, all I've seen is

  1. inability to build software outside of MacPorts (solution: report problem to developers of software)
  2. broken ports detected by MacPorts (solution: MacPorts already rebuilt the ports)

comment:10 Changed 7 years ago by holtzermann17@…

I did report the problem to Emacs developers, here: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=17043 And since my work-around works for me, I'm happy. I think it's fine to close.

comment:11 in reply to:  2 ; Changed 7 years ago by ryandesign (Ryan Schmidt)

Resolution: invalid
Status: newclosed

Replying to holtzermann17@…:

In file included from /usr/X11/include/X11/Xft/Xft.h:39:
/usr/X11/include/ft2build.h:56:10: fatal error: 'freetype/config/ftheader.h' file not found
#include <freetype/config/ftheader.h>
         ^
1 error generated.

I didn't notice before that this was the copy of freetype in /usr/X11, not the copy MacPorts provides. The copy in /usr/X11 is undoubtedly older than 2.5.1. The copy in MacPorts is 2.5.3. In 2.5.1 the freetype developers changed where their headers are located. You can't mix software compiled with freetype < 2.5.1 with software compiled with freetype >= 2.5.1.

comment:12 in reply to:  11 Changed 7 years ago by ryandesign (Ryan Schmidt)

Replying to ryandesign@…:

I didn't notice before that this was the copy of freetype in /usr/X11, not the copy MacPorts provides.

Or rather, the copy of Xft from /usr/X11, rather than the copy of Xft from MacPorts. Either way, please use dependencies only from MacPorts (or only from /usr/X11) and do not mix and match.

comment:13 Changed 7 years ago by holtzermann17@…

Thanks for pointing that out Ryan! I've passed the info along to the Emacs dev team.

comment:14 Changed 7 years ago by holtzermann17@…

Further update: I got some help from the Emacs devs WRT setting required environment variables. But, unless I apply my patch, I still get a rather similar error to the one I mentioned before:

In file included from /opt/local/include/X11/Xft/Xft.h:39:
/opt/X11/include/ft2build.h:56:10: fatal error: 'freetype/config/ftheader.h' file not found

According to one of the Emacs devs:

It looks to me like the /opt/local version is mistakenly including an /opt/X11 version; but I'm not familiar with MacPorts.

Is this really a mistake?

Here's how I built it:

$ export CFLAGS='-I/opt/local/include/ -I/opt/X11/include/ -I/opt/local/lib/'
$ export LDFLAGS='-I/opt/local/include/ -I/opt/X11/include/ -I/opt/local/lib/'
$ export CPPFLAGS='-I/opt/local/include/ -I/opt/X11/include/ -I/opt/local/lib/'
$ ./configure
$ make bootstrap

As a good sign, with this extra pre-configuration step, ./configure now finds jpeg and gif libraries that it didn't find before. But Xft still presents a problem.

He cautions me:

Perhaps those are not the right settings. Perhaps these days you also need to export PKG_CONFIG_PATH pointing to the right MacPorts location. I'd consult MacPorts documentation related to building software.

TBH, given the evidence about the other libraries, it seems to me that these are the right settings, but if you also think that the configuration isn't right, could you please point me to the relevant doc?

comment:15 in reply to:  14 Changed 7 years ago by ryandesign (Ryan Schmidt)

Replying to holtzermann17@…:

Further update: I got some help from the Emacs devs WRT setting required environment variables. But, unless I apply my patch, I still get a rather similar error to the one I mentioned before:

In file included from /opt/local/include/X11/Xft/Xft.h:39:
/opt/X11/include/ft2build.h:56:10: fatal error: 'freetype/config/ftheader.h' file not found

According to one of the Emacs devs:

It looks to me like the /opt/local version is mistakenly including an /opt/X11 version; but I'm not familiar with MacPorts.

Is this really a mistake?

Yes, that would be a mistake. Don't mix MacPorts libraries in /opt/local with Xquartz libraries in /opt/X11.

Here's how I built it:

$ export CFLAGS='-I/opt/local/include/ -I/opt/X11/include/ -I/opt/local/lib/'
$ export LDFLAGS='-I/opt/local/include/ -I/opt/X11/include/ -I/opt/local/lib/'
$ export CPPFLAGS='-I/opt/local/include/ -I/opt/X11/include/ -I/opt/local/lib/'
$ ./configure
$ make bootstrap

-I flags belong in CPPFLAGS only, and should only reference include directories.
-L flags belong in LDFLAGS only, and should only reference lib directories.

Try these settings:

export LDFLAGS="-L/opt/local/lib"
export CPPFLAGS="-I/opt/local/include"

comment:16 Changed 7 years ago by holtzermann17@…

Thanks, that works, without patching anything! Thanks so much! I'll mention the config to the Emacs devs and maybe they will be able to set the flags automatically.

Thanks again for helping me sort out the confusion!

comment:17 Changed 7 years ago by ryandesign (Ryan Schmidt)

In most cases, you should expect to have to set those flags yourself. emacs and other software doesn't know where your dependencies are located.

Note: See TracTickets for help on using tickets.