bugThe FreeType Project - Bugs: bug #38235, freetype-config: lacks proper path...


bug #38235: freetype-config: lacks proper path substitution

Submitted by:  Michał Górny <michalgorny>
Submitted on:  Sat 02 Feb 2013 12:34:28 PM UTC  
Severity:  3 - Normal Item Group:  None
Status:  Fixed Privacy:  Public
Assigned to:  Werner LEMBERG <wl> Open/Closed:  Closed
Planned Release:  2.5.4

Add a New Comment(Rich Markup)

You are not logged in

Please log in, so followups can be emailed to you.


( Jump to the original submission)

Thu 03 Apr 2014 02:26:19 PM UTC, comment #15:

Reported upstream as


Werner LEMBERG <wl>
Project AdministratorIn charge of this item.
Thu 27 Mar 2014 04:40:49 PM UTC, comment #14:

I've just checked on a Windows box: This is indeed a bug in pkg-config! pkg-config's prefix override mechanism fails for prefix values surrounded by doublequotes.

This should be now fixed in git, please test.

Werner LEMBERG <wl>
Project AdministratorIn charge of this item.
Thu 27 Mar 2014 07:00:27 AM UTC, comment #13:

Hi Werner,
Yeah, this is exactly what I was talking about.
I will try to search this (bug?) on Google and reach the pkg-config team.
BTW, IIRC, no one among open source projects has used


in the pc files. They're all


For a better compatibility, could you please consider following the usual way of doing this, which is also the way the official document does, removing those quote marks in the next release? And pkg-config doesn't look like releasing more than twice a year.
Thank you.

wesley <wesley>
Thu 27 Mar 2014 06:35:28 AM UTC, comment #12:

If I understand the issue correctly: You say that




makes a difference with `pkg-config'? This definitely looks like a bug in pkg-config! The quotes are there only to allow whitespace in the string; they are not there to disable pkg-config's `--prefix-variable' method. [Honestly, I would rather guess that not using ${prefix} in the final .pc file is the issue, but your description sounds different.]

Please contact the pkg-config people and report back what they say.

Werner LEMBERG <wl>
Project AdministratorIn charge of this item.
Thu 27 Mar 2014 06:02:53 AM UTC, comment #11:

Hi Werner,
I saw your reply in bug #41959. But I don't think it's a duplication.

I've tried

And freetype2.pc reads

unix-def.mk reads

sed in unix-def.mk did the job, extracting that '${libdir}' I've passed to includedir.

But the problem I've mentioned before is, pkg-config generates a wrong, which is a absolute path for cflags. In other words, if I type
I get
That's definitely wrong. And this mistake comes from the quote marks around /opt/lib/freetype2/include/freetype2.

And the solution is removing those quote marks.
freetype2.pc.in reads
(Note that the quote marks are gone.)

And freetype2.pc would reads

pkg-config would return the right place I want, in Win32 and MSYS.

wesley <wesley>
Wed 03 Jul 2013 08:55:37 PM UTC, comment #10:

Thanks for pointing to the pkg-config option.

So a `--dont-define-prefix' option for FreeType's `configure' script looks promising :-)

I'm re-opening this bug report so that this issue won't be forgotten. However, I don't have time currently to write a patch by myself, sorry.

Werner LEMBERG <wl>
Project AdministratorIn charge of this item.
Wed 03 Jul 2013 01:31:10 PM UTC, comment #9:

Actually it is a feature - see below for the related pkg-config option (to disable the default relocatable feature) regarding this on Win32.

Aside from the pkg-config issue on win32 and a nit that this change modifies the behavior vs other generated -config or .pc files (which adds paths with ${prefix} if they are sub-directories of "prefix"), I can live with it if nobody else find it causing problems.

I can just revert it over here, but thought to bring attention to it in case there are fallout from other sources.

----- main.c -----
#ifdef G_OS_WIN32
{ "dont-define-prefix", 0, 0, G_OPTION_ARG_NONE, &dont_define_prefix,
"don't try to override the value of prefix for each .pc file found with "
"a guesstimated value based on the location of the .pc file", NULL },

Martin Schlemmer <azarah>
Wed 03 Jul 2013 12:37:54 PM UTC, comment #8:

Well, in my opinion you are abusing pkgconfig for implementing relocation, something it hasn't been designed for, AFAIK.

Can you provide a patch to add an option to `configure' which does what you want?

Werner LEMBERG <wl>
Project AdministratorIn charge of this item.
Wed 03 Jul 2013 11:44:48 AM UTC, comment #7:

This change breaks on Win32 when using MSYS and MinGW - not as much the freetype-config changes as the pkg-config changes.

Generally on Win32 we build things with a non-existing prefix to make sure that they are relocatable.

Because of above, pkgconfig treats 'prefix' as relative to the 'bin' directory, not the actual value of 'prefix', and then use it and substitute it in 'libdir', etc. making things relocatable. With this change however because 'libdir' (as well as the other variables in the .pc) is no longer '${prefix}/lib' but a hardcoded path, gcc/ld fails to find includes/libraries.

Also, most (if not all) the other software packages out there that either use pkg-config or a XX-config work like before this patch, IMHO if you want to do non-standard things like "./configure --includedir='${libdir}'/freetype2/include", you should know to patch things to work around it.

Martin Schlemmer <azarah>
Fri 08 Feb 2013 09:07:00 PM UTC, comment #6:

Seems to work great. Thanks.

Michał Górny <michalgorny>
Fri 08 Feb 2013 12:00:35 PM UTC, comment #5:

Fixed in git. Please test.

Werner LEMBERG <wl>
Project AdministratorIn charge of this item.
Sat 02 Feb 2013 01:43:55 PM UTC, comment #4:

Well, I already did but savannah broke it a bit. Lemme rework it.

freetype-config.in does not require any changes itself.

configure.ac requires removing 'freetype-config' from AC_CONFIG_FILES.

Makefile needs to generate freetype-config from freetype-config.in. The generic rule would be:

with the s|| lines repeated for all variables used in freetype-config.in, and global-scope variables set in Makefiles appropriately.

Michał Górny <michalgorny>
Sat 02 Feb 2013 01:15:20 PM UTC, comment #3:

If you can provide a patch for freetype-config.in together with a generic makefile rule which does what you think it should do, this would be great. Don't worry about the small details and integration into FreeType, I'll handle that later on.

Werner LEMBERG <wl>
Project AdministratorIn charge of this item.
Sat 02 Feb 2013 01:03:50 PM UTC, comment #2:

That is no problem, just s/automake/make/.

And I can't point to a foo-config script which does the right thing because those scripts never do the right thing. I would be happy to provide the patch for it but this build system is so ugly I can't find the right place.

The general method is to remove 'freetype-config' from AC_CONFIG_FILES, and do something similar to the following generic snippet in the Makefile:

$(BUILD_DIR)/freetype-config: $(TOP_DIR)/builds/unix/freetype-config.in
rm -f $@ $@.tmp
sed -e 's|@libdir@|$(libdir)|' \
-e 's|@includedir@|$(includedir)|' $< > $@.tmp
chmod +x $@.tmp
chmod a-w $@.tmp
mv $@.tmp $@

Please note that I may have used the wrong build path variables, and you need to put all the @@ substitutions to that sed call. Also, you need to make the install target depend on the generated file.

Michał Górny <michalgorny>
Sat 02 Feb 2013 12:39:25 PM UTC, comment #1:

Well, FreeType doesn't use automake...

Can you point to a foo-config script which you believe does the right thing?

Werner LEMBERG <wl>
Project AdministratorIn charge of this item.
Sat 02 Feb 2013 12:34:28 PM UTC, original submission:

The freetype-config script is created using autoconf substitution while it should use proper sed substitution done by automake. This results in semi-random failures with various path settings.

For example, using:

./configure --includedir='${libdir}'/freetype2/include

results in proper installation yet freetype-config reads:


which is of course invalid. Although changing order would help here, it will break again if someone used '$(libdir)' instead (which is a valid option to make) or some other variable which was not explicitly listed by the author.

The proper solution is to let automake perform the path variable substitution and use evaluated paths in the file. The common way of doing that is to use sed.

Michał Górny <michalgorny>


(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach Files:

No files currently attached


Depends on the following items: None found

Items that depend on this one: None found


Carbon-Copy List
  • -email is unavailable- added by wesley (Posted a comment)
  • -email is unavailable- added by azarah (Posted a comment)
  • -email is unavailable- added by wl (Posted a comment)
  • -email is unavailable- added by michalgorny (Submitted the item)

    Do you think this task is very important?
    If so, you can add your encouragement to it.
    This task has 0 encouragements so far.

    Only logged-in users can vote.




    Follow 12 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2014-03-27 wl StatusNeed Info => Fixed
        Open/ClosedOpen => Closed
        Planned Release2.4.12 => 2.5.4
    2014-03-27 wl StatusConfirmed => Need Info
    2013-07-03 wl StatusNeed Info => Confirmed
        Open/ClosedClosed => Open
    2013-07-03 wl StatusFixed => Need Info
    2013-02-08 wl StatusNeed Info => Fixed
        Open/ClosedOpen => Closed
        Planned ReleaseNone => 2.4.12
    2013-02-02 wl StatusNone => Need Info
    2013-02-02 wl Assigned toNone => wl

    Back to the top

    Powered by Savane 3.3