All of lore.kernel.org
 help / color / mirror / Atom feed
From: Alexey Brodkin <Alexey.Brodkin@synopsys.com>
To: buildroot@busybox.net
Subject: [Buildroot] [PATCH] qt5: Disable passing of -isystem flag in CXXFLAGS
Date: Wed, 28 Sep 2016 08:54:51 +0000	[thread overview]
Message-ID: <1475052878.9922.15.camel@synopsys.com> (raw)
In-Reply-To: <6467f1b7-7326-02f1-caf1-671099a34eac@mind.be>

Hi?Arnout,

On Wed, 2016-09-28 at 00:33 +0200, Arnout Vandecappelle wrote:
> 
> On 26-09-16 13:30, Alexey Brodkin wrote:
> > 
> > Hi Arnout,
> > 
> > On Sat, 2016-09-24 at 00:11 +0200, Arnout Vandecappelle wrote:
> [snip]
> > 
> > > 
> > > ?I still don't understand how the -I$(STAGING_DIR)/usr/include gets added, by
> > > the way. Isn't pkg-config supposed to suppress those, because they already are
> > > in the default search path? For instance, on my system I have a xf86dgaproto.pc
> > > which contains Cflags: -I${includedir}, but pkg-config --cflags xf86dgaproto
> > > gives empty.
> 
> ?I mean that it's _our_ pkg-config that does the wrong thing.
> 
> ------ output/staging/usr/lib/pkgconfig/libpcre.pc --------
> # Package Information for pkg-config
> 
> prefix=/usr
> exec_prefix=/usr
> libdir=${exec_prefix}/lib
> includedir=${prefix}/include
> 
> Name: libpcre
> Description: PCRE - Perl compatible regular expressions C library with 8 bit
> character support
> Version: 8.39
> Libs: -L${libdir} -lpcre
> Libs.private:
> Cflags: -I${includedir}
> ------------------------------------------------------------
> 
> output/host/usr/bin/pkg-config --cflags libpcre
> -IXXX/output/host/usr/arm-buildroot-linux-musleabihf/sysroot/usr/include
> 
> ?According to me, this should have returned empty.
> 
> ?So I've checked, and it looks like this is a feature of the full-fledged
> pkg-config that pkgconf doesn't have:
> 
> pkg-config --cflags libpcre
> <empty>
> 
> output/host/usr/bin/pkgconf --cflags libpcre
> -I/usr/include

Well note in our case pkg-config is just a wrapper script
that is created out of BR's "package/pkgconf/pkg-config.in":
--------------------->8--------------------
cat ./output/host/usr/bin/pkg-config
#!/bin/sh
PKG_CONFIG_LIBDIR=${PKG_CONFIG_LIBDIR:-/XXX/output/host/usr/arc-buildroot-linux-
uclibc/sysroot/usr/lib/pkgconfig:/XXX/output/host/usr/arc-buildroot-linux-uclibc/sysroot/usr/share/pkgconfig}
PKG_CONFIG_SYSROOT_DIR=${PKG_CONFIG_SYSROOT_DIR:-/XXX/output/host/usr/arc-buildroot-linux-uclibc/sysroot} $(dirname
$0)/pkgconf??$@
--------------------->8--------------------

So it all boils down to:
1) "pkg-config" case:
--------------------->8--------------------
PKG_CONFIG_LIBDIR=${PKG_CONFIG_LIBDIR:-/XXX/output/host/usr/arc-buildroot-linux-uclibc/sysroot/usr/lib/pkgconfig}
PKG_CONFIG_SYSROOT_DIR=${PKG_CONFIG_SYSROOT_DIR:-/XXX/output/host/usr/arc-buildroot-linux-uclibc/sysroot}
./output/host/usr/bin/pkgconf --libs icu-i18n
-licui18n -L/XXX/output/host/usr/arc-buildroot-linux-uclibc/sysroot/usr/lib -licuuc -licudata
--------------------->8--------------------

2. Pure "pkgconf" case:
--------------------->8--------------------
./output/host/usr/bin/pkgconf --libs icu-i18n
-licui18n -licuuc -licudata
--------------------->8--------------------

> ?So ideally, we should patch pkgconf (and send upstream) to remove the default
> search paths.

Given my comments above I'm not really sure it's pkgconf who's guilty.

Any thoughts?

-Alexey

  reply	other threads:[~2016-09-28  8:54 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-09-23 14:58 [Buildroot] [PATCH] qt5: Disable passing of -isystem flag in CXXFLAGS Alexey Brodkin
2016-09-23 22:11 ` Arnout Vandecappelle
2016-09-26 11:30   ` Alexey Brodkin
2016-09-27 22:33     ` Arnout Vandecappelle
2016-09-28  8:54       ` Alexey Brodkin [this message]
2016-09-29 21:05         ` Arnout Vandecappelle
2016-09-29 21:34           ` Arnout Vandecappelle
2016-09-30  8:55             ` Alexey Brodkin
2016-10-05  7:12               ` Alexey Brodkin
2016-09-30  8:54           ` Alexey Brodkin
2016-09-28  8:57       ` Thomas Petazzoni
2016-09-29 21:30         ` Arnout Vandecappelle
2016-10-05  8:01 ` Thomas Petazzoni

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1475052878.9922.15.camel@synopsys.com \
    --to=alexey.brodkin@synopsys.com \
    --cc=buildroot@busybox.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.