2

I want to change the directory where pkg-config looks for .pr files. I'm using pkg-config under MinGW on Windows. I found that this can be done by changing the PKG_CONFIG_PATH environment variable using export PKG_CONFIG_PATH=[path]. The .pr files I want pkg-config to find are not installed in the MinGW directory, but somewhere in the "normal" windows file system (C:\Program Files (x86)\Gtk+\lib\pkgconfig).

Now to my problem: If I run export PKG_CONFIG_PATH="/c/Program Files (x86)/Gtk+/lib/pkg-config/ and then run pkg-config --cflags gtk+-win32-2.0 I get the following output.

$ pkg-config --cflags gtk+-win32-2.0 --debug
Option --debug seen
Error printing enabled by default due to use of --version, --libs, --cflags, --libs-only-l, --libs-only-L, --libs-only-other, --cflags-only-I, --cflag
s-only-other or --list. Value of --silence-errors: 0
Error printing enabled
Adding virtual 'pkg-config' package to list of known packages
Cannot open directory 'c' in package search path: No such file or directory
Cannot open directory '/Program Files (x86)/Gtk+/lib/pkgconfig/' in package search path: No such file or directory
Scanning directory '/usr/lib/pkgconfig'
Ignoring file '.' in search directory; not a .pc file
Ignoring file '..' in search directory; not a .pc file

etc.

So how must I specify the path of the .pr files so pkg-config can find it? This is not an issue if I install the .pr files in the MinGW directory, they are found without changing the environment variable.

simon
  • 1,125
  • 1
  • 10
  • 20

1 Answers1

1

No, you should use $(GTK_COMPILE) in your main.o Makefile target instead of $(GTK_LINK). $(GTK_COMPILE) calls pkg-config --cflags which will return the CFLAGS you need to compile (the location of the header files). The LIBS you need for linking, not compiling

axel_c
  • 6,557
  • 2
  • 28
  • 41
  • Thanks for your reply. Stupid mistake. However, after correcting it, I still get the same error. If I type in `pkg-config --cflags gtk+-2.0` all the directories which are searched for header files are in `/usr/include/`. I would like to change that to a custom directory. Can you tell me how to do that? – simon Mar 22 '12 at 14:58
  • 1
    It's not the cleanest approach, but maybe you could just edit the .pc file by hand to make the paths point to the right place? – axel_c Mar 22 '12 at 15:02
  • The problem is that I'm not sure which `.pc` files are actually used. I tried modifying the ones in the `C:\Program Files (x86)\Gtk+\lib\pkgconfig` folder, but to no effect. I then checked the `pkg-config` output with the `--debug` flag and there is said that it couldn't open my directory specified in the `PKG_CONFIG_PATH` variable. If I type `echo $PKG_CONFIG_PATH` MinGW gives out `/c/Program Files (x86)/Gtk+/lib/pkgconfig/`. I am able to `cd` to that directory but for some reason `pkg-config` can't open it. – simon Mar 22 '12 at 15:20
  • Maybe because of the spaces in the path? Some programs may not work correctly with those. Try changing PKG_CONFIG_PATH to replace spaces with "\ " (that's "\" plus a space) and see if it helps. – axel_c Mar 22 '12 at 15:28
  • I also tried that but to no effect. echoing `PKG_CONFIG_PATH` after setting it using "\ " instead of " " gives the same output as above (with spaces). – simon Mar 22 '12 at 15:33
  • can you paste the output of running pkg-config with --debug? – axel_c Mar 22 '12 at 15:36
  • I have updated my initial question with the debug output. In essence, the question has now become if it is even possible to add paths outside the MinGW directory to the `PKG_CONFIG_PATH` variable. – simon Mar 22 '12 at 15:47
  • It's choking on /c, see how it interprets it as a separate directory. I haven't used cygwin for ages but weren't you supposed to use /cygdrive/c or something like that to access the 'normal' windows filesystem? – axel_c Mar 22 '12 at 15:55
  • That's what the question boils down to. I changed `PKG_CONFIG_PATH` to `/cygdrive/c/` and the debug output is `Cannot open directory C:/MinGW/msys/1.0/cygdrive/c/ in package search path: No such file or directory`. So I guess there must be some other way to access the normal Windows files/directories. – simon Mar 22 '12 at 16:07