Demain

Demain

[Andreas Enge]

Seras-tu dans ton bureau? Je m'énerve sur cairo...

Andreas

Re: Demain

[Andreas Enge]

Am Donnerstag, 13. Juni 2013 schrieb Andreas Enge:
> Seras-tu dans ton bureau? Je m'énerve sur cairo...

Sorry, wrongly addressed personal mail to Ludovic!

But maybe one of you knows the answer to my problem:
I created a recipe for cairo, and lots of tests fail. Now I wonder if this 
is the expected behaviour...

Linux from Scratch claims "This package does not have a working 
testsuite.":
   http://www.linuxfromscratch.org/blfs/view/svn/x/cairo.html
The archlinux package has disabled the tests, most of which are reported as 
failing:
   https://projects.archlinux.org/svntogit/packages.git/tree/trunk/PKGBUILD?h=packages/cairo
Finally, the file test/README seems to imply that the test suite is rather 
meant for internal development than to be run when installing:
   http://cgit.freedesktop.org/cairo/tree/test/README

Andreas

Re: Demain

[Cyril Roelandt]

On 06/13/2013 11:37 PM, Andreas Enge wrote:
> Am Donnerstag, 13. Juni 2013 schrieb Andreas Enge:
>> Seras-tu dans ton bureau? Je m'énerve sur cairo...
>
> Sorry, wrongly addressed personal mail to Ludovic!
>
> But maybe one of you knows the answer to my problem:
> I created a recipe for cairo, and lots of tests fail. Now I wonder if this
> is the expected behaviour...
>

How many is "lots" ? :p Do you see the same test failures when trying to 
compile cairo by hand "outside of Guix" ?

> Linux from Scratch claims "This package does not have a working
> testsuite.":
>     http://www.linuxfromscratch.org/blfs/view/svn/x/cairo.html
> The archlinux package has disabled the tests, most of which are reported as
> failing:
>     https://projects.archlinux.org/svntogit/packages.git/tree/trunk/PKGBUILD?h=packages/cairo
> Finally, the file test/README seems to imply that the test suite is rather
> meant for internal development than to be run when installing:
>     http://cgit.freedesktop.org/cairo/tree/test/README

Then this is probably not an issue. Can you link sample programs to 
cairo and see if they work ?

Cyril.

Re: Demain

[Andreas Enge]

Am Freitag, 14. Juni 2013 schrieb Cyril Roelandt:
> Do you see the same test failures when trying to
> compile cairo by hand "outside of Guix" ?

By hand I did not manage to compile due to my unpleasant mixture of debian 
and guix libraries.

> Then this is probably not an issue. Can you link sample programs to
> cairo and see if they work ?

Do you know of an interesting sample program I could try? For me, cairo is 
just a prerequisite for pango, which is a prerequisite for gtk, which is a 
prerequisite for ripperx, so there will be some time until I end up with 
the program I am interested in...

Andreas

Re: Demain

[Ludovic Courtès]

Hello!

Thanks for taking care of Cairo!

Andreas Enge <andreas@enge.fr> skribis:

> Linux from Scratch claims "This package does not have a working 
> testsuite.":
>    http://www.linuxfromscratch.org/blfs/view/svn/x/cairo.html
> The archlinux package has disabled the tests, most of which are reported as 
> failing:
>    https://projects.archlinux.org/svntogit/packages.git/tree/trunk/PKGBUILD?h=packages/cairo
> Finally, the file test/README seems to imply that the test suite is rather 
> meant for internal development than to be run when installing:
>    http://cgit.freedesktop.org/cairo/tree/test/README

All this sounds like an indication that we won’t be able to make much
out of this test suite.  I would disable it, and ideally ask on their
IRC channel or mailing list what they think.

Ludo’.

Pango

[Andreas Enge]

Am Freitag, 14. Juni 2013 schrieb Ludovic Courtès:
> All this sounds like an indication that we won’t be able to make much
> out of this test suite.  I would disable it

Okay; I just pushed cairo without tests.

Now the problem is pango. It finds cairo, but ends up with

checking for pkg-config... /nix/store/jdr6v3aqsy0bw74rwac8g77a2qag81ra-pkg-
config-0.27.1/bin/pkg-config
checking pkg-config is at least version 0.9.0... yes
checking for HARFBUZZ... no
no
checking for CoreText availability... no
checking for CAIRO... yes
checking which cairo font backends could be used... none
configure: Disabling cairo support
configure: error: *** Could not enable any backends.
*** Must have at least one backend to build Pango.

Without saying so, pango seems to depend on harfbuzz on gnu/linux (on 
macosx it uses quartz, for windows there are other tests); but we need 
fontconfig/freetype, which is not even searched for without harfbuzz, 
according to the configure.ac:

#
# Check for fontconfig
#
have_fontconfig=false
if $have_harfbuzz ; then
  PKG_CHECK_MODULES(FONTCONFIG, fontconfig >= 2.10.91, 
have_fontconfig=true, AC_MSG_RESULT([no]))
fi
#
# Checks for FreeType
#
have_freetype=false
if $have_fontconfig ; then
  # The first version of freetype with a .pc file is 2.1.5.  That's recent
  # enough for all the functions we use I guess.  No version check needed.
  PKG_CHECK_MODULES(FREETYPE, freetype2, have_freetype=true, 
AC_MSG_RESULT([no]))
fi

This dependency is new since pango 1.31; I might go back to version 1.30, 
for which there is a recipe in nix.

Or try to compile harfbuzz; but the current version 0.9.18 fails its tests 
with endless error messages such as
test_unicode-test-unicode.o:(.rodata+0x1d0): undefined reference to 
`hb_unicode_script'

Version 0.9.4 (for which there is a recipe in nix) compiles and passes its 
tests. This looks like a need for bisection...

Enough for tonight,

Andreas

Re: Pango

[Andreas Enge]

Am Freitag, 14. Juni 2013 schrieb Andreas Enge:
> Or try to compile harfbuzz; but the current version 0.9.18 fails its
> tests with endless error messages such as
> test_unicode-test-unicode.o:(.rodata+0x1d0): undefined reference to
> `hb_unicode_script'

Adding a dependency on the seemingly optional icu solved this problem.

And now pango also compiles!

Andreas

Re: Pango

[Cyril Roelandt]

On 06/14/2013 11:25 PM, Andreas Enge wrote:
> Am Freitag, 14. Juni 2013 schrieb Ludovic Courtès:
>> >  All this sounds like an indication that we won’t be able to make much
>> >  out of this test suite.  I would disable it
> Okay; I just pushed cairo without tests.

In 6131c43d, you also added "git.scm" to Makefile.am. I think it should 
be removed.

Btw, are you working on packaging git ? If so, I think the code should 
be in gnu/packages/version-control.scm rather than in a new file.

Cyril.

Re: Pango

[Andreas Enge]

[-- Attachment #1: Type: Text/Plain, Size: 611 bytes --]

Am Samstag, 15. Juni 2013 schrieb Cyril Roelandt:
> In 6131c43d, you also added "git.scm" to Makefile.am. I think it should
> be removed.

Thanks for spotting this! How about you remove the line at the same time as 
applying your patch moving subversion.scm into version-control.scm?

> Btw, are you working on packaging git ? If so, I think the code should
> be in gnu/packages/version-control.scm rather than in a new file.

Indeed, but it failed its tests and looked painful to debug ;-)

I am attaching my current efforts; if you or someone else would like to 
pick up from there, you are welcome.

Andreas

[-- Attachment #2: git.scm --]
[-- Type: text/x-scheme, Size: 2757 bytes --]

;;; GNU Guix --- Functional package management for GNU
;;; Copyright © 2013 Andreas Enge <andreas@enge.fr>
;;;
;;; This file is part of GNU Guix.
;;;
;;; GNU Guix is free software; you can redistribute it and/or modify it
;;; under the terms of the GNU General Public License as published by
;;; the Free Software Foundation; either version 3 of the License, or (at
;;; your option) any later version.
;;;
;;; GNU Guix is distributed in the hope that it will be useful, but
;;; WITHOUT ANY WARRANTY; without even the implied warranty of
;;; MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
;;; GNU General Public License for more details.
;;;
;;; You should have received a copy of the GNU General Public License
;;; along with GNU Guix.  If not, see <http://www.gnu.org/licenses/>.

(define-module (gnu packages git)
  #:use-module ((guix licenses)
                #:renamer (symbol-prefix-proc 'license:))
  #:use-module (guix packages)
  #:use-module (guix download)
  #:use-module (guix build-system gnu)
  #:use-module (gnu packages)
  #:use-module (gnu packages compression)
  #:use-module (gnu packages curl)
  #:use-module ((gnu packages gettext)
                #:renamer (symbol-prefix-proc 'gnu:))
  #:use-module (gnu packages openssl)
  #:use-module (gnu packages perl)
  #:use-module (gnu packages python)
  #:use-module (gnu packages xml))

(define-public git
  (package
   (name "git")
   (version "1.8.2.2")
   (source (origin
            (method url-fetch)
            (uri (string-append "http://git-core.googlecode.com/files/git-"
                                version ".tar.gz"))
            (sha256
             (base32
              "152757vwdzr0lphv9skb60xijj0r46cp83s6pvhvcarhva7f6382"))))
   (build-system gnu-build-system)
   (inputs
    `(("curl" ,curl)
      ("expat" ,expat)
      ("gettext" ,gnu:gettext)
      ("openssl" ,openssl)
      ("perl" ,perl)
      ("python" ,python)
      ("zlib" ,zlib)))
   (arguments
    `(#:test-target "test"
      #:phases
       (alist-replace
        'configure
        (lambda* (#:key #:allow-other-keys #:rest args)
          (let ((configure (assoc-ref %standard-phases 'configure)))
          (apply configure args)
          (substitute* "Makefile"
            (("/bin/sh") (which "sh"))
            (("/usr/bin/perl") (which "perl"))
            (("/usr/bin/python") (which "python")))))
         %standard-phases)))
   (synopsis "distributed version control system")
   (description
    "Git is a free distributed version control system designed to handle
everything from small to very large projects with speed and efficiency.")
   (license license:gpl2)
   (home-page "http://git-scm.com/")))

Re: Pango

[Andreas Enge]

The include files for pango reside in
   include/pango-1.0/pango/
Then the main include file
   include/pango-1.0/pango/pango.h
includes lines like
   #include <pango/pango-attributes.h>
without the pango-1.0.

I see three solutions:

One can modify the CPATH to include pango-1.0; I do not know how to do this 
automatically so that each and every dependency of pango profits from it.

One can modify each header file (of gtk+, for instance) including 
pango/pango.h to include pango-1.0/pango/pango.h instead, which would be 
rather tedious in the long run.

Or one can add a symlink
   pango -> pango-1.0/pango
with the following patch:
   (arguments
    `(#:phases
       (alist-replace
        'install
        (lambda* (#:key outputs #:allow-other-keys #:rest args)
         (let ((install (assoc-ref %standard-phases 'install))
               (include (string-append (assoc-ref outputs "out") 
"/include")))
           (apply install args)
           ;; Unravel one directory, since pango.h includes directly from
           ;; pango/, not pango-1/pango/.
           (symlink (string-append include "/pango-1.0/pango")
                    (string-append include "/pango"))))

Would the third solution be okay? I already used it for freetype, but there 
the additional directory layer was announced to be suppressed in the near 
future.

As the symlink would only be inside the nix store path for this particular 
package, we could still (in case it comes out) have packages depend on 
pango-2, while others depend on pango-1.0, for instance. But it would 
prevent users from installing pango-2 and pango-1.0 at the same time in 
their user environment, as both would contain the symlink include/pango.


A similar problem occurs with cairo: The header files are in
   include/cairo/cairo.h,
whereas gtk+ has lines such as
   #include <cairo.h>.
Here I would prefer the second solution, as one directory layer to regroup 
the header files of a package such as cairo looks reasonable to me to avoid 
clutter.

What do you think?


And a minor question: Would you prefer the package name "gtk" or "gtk+"?

Andreas

Re: Pango

[Andreas Enge]

As an addendum, the same problem occurs for gdk-pixbuf with an additional 
directory named gdk-pixbuf-2.0.

And there is a cross-package problem:
Inside the pango package, the file pangocairo.h contains
   #include <cairo.h>
So either we must replace this by cairo/cairo.h in the install phase of 
pango, or also unravel one directory structure in the cairo package via a 
symlink cairo.h->cairo/cairo.h.

Or somehow work globally on the CPATHs of all these gnome packages.

Andreas

Re: Pango

[Ludovic Courtès]

Andreas Enge <andreas@enge.fr> skribis:

> This dependency is new since pango 1.31; I might go back to version 1.30, 
> for which there is a recipe in nix.
>
> Or try to compile harfbuzz; but the current version 0.9.18 fails its tests 
> with endless error messages such as
> test_unicode-test-unicode.o:(.rodata+0x1d0): undefined reference to 
> `hb_unicode_script'
>
> Version 0.9.4 (for which there is a recipe in nix) compiles and passes its 
> tests. This looks like a need for bisection...

Woow, I had never heard of harfbuzz.

Do I get it right that the simplest options are: old harfbuzz + new
Pango, or old Pango alone?

I don’t know what functionality harfbuzz enables, but the above options
look acceptable to me as a start.

Ludo’.

Re: Pango

[Ludovic Courtès]

Andreas Enge <andreas@enge.fr> skribis:

> Am Freitag, 14. Juni 2013 schrieb Andreas Enge:
>> Or try to compile harfbuzz; but the current version 0.9.18 fails its
>> tests with endless error messages such as
>> test_unicode-test-unicode.o:(.rodata+0x1d0): undefined reference to
>> `hb_unicode_script'
>
> Adding a dependency on the seemingly optional icu solved this problem.
>
> And now pango also compiles!

Ah, even better.  :-)

Ludo'.

Re: Pango

[Ludovic Courtès]

Andreas Enge <andreas@enge.fr> skribis:

>    (inputs
>     `(("curl" ,curl)
>       ("expat" ,expat)
>       ("gettext" ,gnu:gettext)
>       ("openssl" ,openssl)
>       ("perl" ,perl)
>       ("python" ,python)
>       ("zlib" ,zlib)))
>    (arguments
>     `(#:test-target "test"
>       #:phases
>        (alist-replace
>         'configure
>         (lambda* (#:key #:allow-other-keys #:rest args)
>           (let ((configure (assoc-ref %standard-phases 'configure)))
>           (apply configure args)
>           (substitute* "Makefile"
>             (("/bin/sh") (which "sh"))
>             (("/usr/bin/perl") (which "perl"))
>             (("/usr/bin/python") (which "python")))))
>          %standard-phases)))

Note that Perl and Python seem to be used at build time.  Thus, they
should be listed in ‘native-inputs’ rather than ‘inputs’, so that they
can actually be executed when cross-compiling.

Ludo’.

Re: Pango

[Ludovic Courtès]

Andreas Enge <andreas@enge.fr> skribis:

> The include files for pango reside in
>    include/pango-1.0/pango/
> Then the main include file
>    include/pango-1.0/pango/pango.h
> includes lines like
>    #include <pango/pango-attributes.h>
> without the pango-1.0.
>
> I see three solutions:
>
> One can modify the CPATH to include pango-1.0; I do not know how to do this 
> automatically so that each and every dependency of pango profits from it.
>
> One can modify each header file (of gtk+, for instance) including 
> pango/pango.h to include pango-1.0/pango/pango.h instead, which would be 
> rather tedious in the long run.
>
> Or one can add a symlink
>    pango -> pango-1.0/pango

Here’s a fourth one: do not change anything.  :-)

Normally pango-1.0.pc has -I.../include/pango-1.0 in its Cflags, doesn’t it?

That is a common convention for “parallel installability”, and it
requires users to use pkg-config to find out what the right -I flags
are.

HTH,
Ludo’.

Re: Pango

[Andreas Enge]

Am Samstag, 15. Juni 2013 schrieb Ludovic Courtès:
> Here’s a fourth one: do not change anything.  :-)
> Normally pango-1.0.pc has -I.../include/pango-1.0 in its Cflags, doesn’t
> it?
> 
> That is a common convention for “parallel installability”, and it
> requires users to use pkg-config to find out what the right -I flags
> are.

Maybe, but then guix also needs to use pkg-config to find out the right -I 
flags.

Currently, when trying "guix build gtk", which has pango as input, the 
CPATH contains
   /nix/store/ac9zyl88qyp6gbidcyrzj8rdngbkqppr-pango-1.34.1/include ,
whereas pango.pc contains the line
   Cflags: -I${includedir}/pango-1.0
And compilation stops with the expected error:
In file included from ../gdk/gdkscreen.h:32:0,
                 from ../gdk/gdkapplaunchcontext.h:31,
                 from ../gdk/gdk.h:32,
                 from gtkaccelgroup.h:35,
                 from gtkaccelgroup.c:31:
../gdk/gdktypes.h:37:25: fatal error: pango/pango.h: No such file or 
directory
compilation terminated.

Andreas

Re: Pango

[Ludovic Courtès]

Andreas Enge <andreas@enge.fr> skribis:

> Am Samstag, 15. Juni 2013 schrieb Ludovic Courtès:
>> Here’s a fourth one: do not change anything.  :-)
>> Normally pango-1.0.pc has -I.../include/pango-1.0 in its Cflags, doesn’t
>> it?
>> 
>> That is a common convention for “parallel installability”, and it
>> requires users to use pkg-config to find out what the right -I flags
>> are.
>
> Maybe, but then guix also needs to use pkg-config to find out the right -I 
> flags.
>
> Currently, when trying "guix build gtk", which has pango as input, the 
> CPATH contains
>    /nix/store/ac9zyl88qyp6gbidcyrzj8rdngbkqppr-pango-1.34.1/include ,

This one is not needed, but it doesn’t harm.

> whereas pango.pc contains the line
>    Cflags: -I${includedir}/pango-1.0
> And compilation stops with the expected error:
> In file included from ../gdk/gdkscreen.h:32:0,
>                  from ../gdk/gdkapplaunchcontext.h:31,
>                  from ../gdk/gdk.h:32,
>                  from gtkaccelgroup.h:35,
>                  from gtkaccelgroup.c:31:
> ../gdk/gdktypes.h:37:25: fatal error: pango/pango.h: No such file or 
> directory

Did you pass pkg-config as an input of GTK+?

Normally, if you do so, PKG_CONFIG_PATH gets defined appropriately, and
then I would expect the build system of GTK+ to use ‘pkg-config pango
--cflags’ in its CFLAGS.

Ludo’.

Re: Pango

[Andreas Enge]

Am Samstag, 15. Juni 2013 schrieb Ludovic Courtès:
> Did you pass pkg-config as an input of GTK+?

Yes.

> Normally, if you do so, PKG_CONFIG_PATH gets defined appropriately, and
> then I would expect the build system of GTK+ to use ‘pkg-config pango
> --cflags’ in its CFLAGS.

Hm. In config.log, I see
   BASE_DEPENDENCIES_CFLAGS='... -
I/nix/store/ac9zyl88qyp6gbidcyrzj8rdngbkqppr-
pango-1.34.1/include/pango-1.0'
   GDK_DEP_CFLAGS='... -I/nix/store/ac9zyl88qyp6gbidcyrzj8rdngbkqppr-
pango-1.34.1/include/pango-1.0'
   CFLAGS='-DGDK_PIXBUF_DISABLE_DEPRECATED -g -O2 -Wall'

Then the failing compilation line:
make[4]: Entering directory `/tmp/nix-build-
gtk+-2.24.18.drv-0/gtk+-2.24.18/gtk'
/nix/store/zch43a56qdchdw0xm3lwpr8ydg8ksx25-bash-4.2/bin/bash ../libtool  
--tag=CC   --mode=compile gcc -DHAVE_CONFIG_H -I. -I.. -
DG_LOG_DOMAIN=\"Gtk\" -
DGTK_LIBDIR=\"/nix/store/f9mvnb95rwcfp87b4kf45qc3iiz9vpnq-
gtk+-2.24.18/lib\" -
DGTK_DATADIR=\"/nix/store/f9mvnb95rwcfp87b4kf45qc3iiz9vpnq-
gtk+-2.24.18/share\" -
DGTK_DATA_PREFIX=\"/nix/store/f9mvnb95rwcfp87b4kf45qc3iiz9vpnq-
gtk+-2.24.18\" -
DGTK_SYSCONFDIR=\"/nix/store/f9mvnb95rwcfp87b4kf45qc3iiz9vpnq-
gtk+-2.24.18/etc\" -DGTK_VERSION=\"2.24.18\" -
DGTK_BINARY_VERSION=\"2.10.0\" -DGTK_HOST=\"x86_64-unknown-linux-gnu\" -
DGTK_COMPILATION -DGTK_PRINT_BACKENDS=\"file,lpr\" -
DGTK_PRINT_PREVIEW_COMMAND=\""evince --unlink-tempfile --preview --print-
settings %s %f"\" -I.. -I../gtk -I.. -I../gdk -I../gdk -
DGTK_DISABLE_DEPRECATED -DGTK_FILE_SYSTEM_ENABLE_UNSUPPORTED -
DGTK_PRINT_BACKEND_ENABLE_UNSUPPORTED -pthread -
I/nix/store/jda9bn6spp9ixh87g2cqlpkfwr5smmw4-glib-2.37.1/include/glib-2.0 -
I/nix/store/jda9bn6spp9ixh87g2cqlpkfwr5smmw4-
glib-2.37.1/lib/glib-2.0/include   -DG_DISABLE_CAST_CHECKS    -
DG_DISABLE_SINGLE_INCLUDES -DATK_DISABLE_SINGLE_INCLUDES -
DGDK_PIXBUF_DISABLE_SINGLE_INCLUDES -DGTK_DISABLE_SINGLE_INCLUDES -
I/nix/store/p05m0ha92h66bkzsaz9zc3sysz589bsh-libxrender-0.9.7/include -
I/nix/store/5n5f85qs2m5lsfqxvdbjwm2rkglkvs8h-libxext-1.3.1/include -
I/nix/store/mbc9brcb0r21f72cbjjh3bpp9xmdmsl0-libx11-1.5.0/include -
I/nix/store/azrr4hrv699q1zixj26d04b6xjc6xj75-libxcb-1.8.1/include -
I/nix/store/mym5vznalgiwmkhykmwwr4jl9x28pvp0-kbproto-1.0.6/include -
I/nix/store/10c9i456r4b00k3w5lxiw1y8bmw52phw-libxdmcp-1.1.1/include -
I/nix/store/wm8jlg8w5kblgda7ll7nxb9lpybz9r36-libxau-1.0.7/include -
I/nix/store/pp4wxag7rwa3yv50hmfzckmm7lcaxi2d-xproto-7.0.23/include -
I/nix/store/7j61z48dz08jq95s89zyv2scbjxcjsc1-xextproto-7.2.1/include -
I/nix/store/fqmifh67d0kfy0fnzr0g2sc0paxk2ywb-renderproto-0.11.1/include    
-DGDK_PIXBUF_DISABLE_DEPRECATED -g -O2 -Wall -MT gtksearchenginesimple.lo -
MD -MP -MF .deps/gtksearchenginesimple.Tpo -c -o gtksearchenginesimple.lo 
gtksearchenginesimple.c
libtool: compile:  gcc -DHAVE_CONFIG_H -I. -I.. -DG_LOG_DOMAIN=\"Gtk\" -
DGTK_LIBDIR=\"/nix/store/f9mvnb95rwcfp87b4kf45qc3iiz9vpnq-
gtk+-2.24.18/lib\" -
DGTK_DATADIR=\"/nix/store/f9mvnb95rwcfp87b4kf45qc3iiz9vpnq-
gtk+-2.24.18/share\" -
DGTK_DATA_PREFIX=\"/nix/store/f9mvnb95rwcfp87b4kf45qc3iiz9vpnq-
gtk+-2.24.18\" -
DGTK_SYSCONFDIR=\"/nix/store/f9mvnb95rwcfp87b4kf45qc3iiz9vpnq-
gtk+-2.24.18/etc\" -DGTK_VERSION=\"2.24.18\" -
DGTK_BINARY_VERSION=\"2.10.0\" -DGTK_HOST=\"x86_64-unknown-linux-gnu\" -
DGTK_COMPILATION -DGTK_PRINT_BACKENDS=\"file,lpr\" "-
DGTK_PRINT_PREVIEW_COMMAND=\"evince --unlink-tempfile --preview --print-
settings %s %f\"" -I.. -I../gtk -I.. -I../gdk -I../gdk -
DGTK_DISABLE_DEPRECATED -DGTK_FILE_SYSTEM_ENABLE_UNSUPPORTED -
DGTK_PRINT_BACKEND_ENABLE_UNSUPPORTED -pthread -
I/nix/store/jda9bn6spp9ixh87g2cqlpkfwr5smmw4-glib-2.37.1/include/glib-2.0 -
I/nix/store/jda9bn6spp9ixh87g2cqlpkfwr5smmw4-
glib-2.37.1/lib/glib-2.0/include -DG_DISABLE_CAST_CHECKS -
DG_DISABLE_SINGLE_INCLUDES -DATK_DISABLE_SINGLE_INCLUDES -
DGDK_PIXBUF_DISABLE_SINGLE_INCLUDES -DGTK_DISABLE_SINGLE_INCLUDES -
I/nix/store/p05m0ha92h66bkzsaz9zc3sysz589bsh-libxrender-0.9.7/include -
I/nix/store/5n5f85qs2m5lsfqxvdbjwm2rkglkvs8h-libxext-1.3.1/include -
I/nix/store/mbc9brcb0r21f72cbjjh3bpp9xmdmsl0-libx11-1.5.0/include -
I/nix/store/azrr4hrv699q1zixj26d04b6xjc6xj75-libxcb-1.8.1/include -
I/nix/store/mym5vznalgiwmkhykmwwr4jl9x28pvp0-kbproto-1.0.6/include -
I/nix/store/10c9i456r4b00k3w5lxiw1y8bmw52phw-libxdmcp-1.1.1/include -
I/nix/store/wm8jlg8w5kblgda7ll7nxb9lpybz9r36-libxau-1.0.7/include -
I/nix/store/pp4wxag7rwa3yv50hmfzckmm7lcaxi2d-xproto-7.0.23/include -
I/nix/store/7j61z48dz08jq95s89zyv2scbjxcjsc1-xextproto-7.2.1/include -
I/nix/store/fqmifh67d0kfy0fnzr0g2sc0paxk2ywb-renderproto-0.11.1/include -
DGDK_PIXBUF_DISABLE_DEPRECATED -g -O2 -Wall -MT gtksearchenginesimple.lo -
MD -MP -MF .deps/gtksearchenginesimple.Tpo -c gtksearchenginesimple.c  -
fPIC -DPIC -o .libs/gtksearchenginesimple.o
In file included from ../gdk/gdkscreen.h:32:0,
                 from ../gdk/gdkapplaunchcontext.h:31,
                 from ../gdk/gdk.h:32,
                 from ../gtk/gtkwidget.h:34,
                 from gtkprivate.h:30,
                 from gtksearchenginesimple.c:38:
../gdk/gdktypes.h:37:25: fatal error: pango/pango.h: No such file or 
directory
compilation terminated.
make[4]: *** [gtksearchenginesimple.lo] Fehler 1

Here, the pango path is not set explicitly and only searched in the CPATH 
set by guix.

Actually, I grepped the sources for '$GTK_DEP_CFLAGS' and found they are 
not used anywhere.

A bug in gtk?

Andreas

Re: Pango

[Andreas Enge]

Am Samstag, 15. Juni 2013 schrieb Ludovic Courtès:
> This is not in a build environment, right?  Is it the same behavior in
> the build environment?

It is in a build environment.

Andreas