From: Arnout Vandecappelle <arnout@mind.be>
To: buildroot@busybox.net
Subject: [Buildroot] [PATCH v2 1/1] libglib2: bump to 2.58.3
Date: Tue, 5 Feb 2019 21:06:00 +0100 [thread overview]
Message-ID: <45ddc4a4-b196-ad26-b96a-e794f1c0b720@mind.be> (raw)
In-Reply-To: <20190205202920.6036210a@windsurf>
On 05/02/2019 20:29, Thomas Petazzoni wrote:
> On Tue, 5 Feb 2019 19:56:23 +0100
> aduskett at gmail.com wrote:
>
>> From: Adam Duskett <Aduskett@gmail.com>
>>
>> In addition:
>> - Update second patch
>> - Remove third and fifth patches (already in version)
>> - Add a new patch to fix a missing header
>> - Add LIBGLIB2_GTK_DOC_HOOK so autoreconf do not fail on the following
>> error:
>> automake: error: cannot open < gtk-doc.make: No such file or directory
>>
>> - Add a new patch: package/libglib2/0005-use-tooldir-in-pc-file.patch
>> This patch fixes the previous autobuild errors by modifying the glib-2.0.pc
>> file and adding a tooldir variable, of which the glib_genmarshal,
>> gobject_query, and glib_mkenums of which will be prefixed. Then a
>
> I am confused by the double "of which" usage in this sentence.
>
>> +define LIBGLIB2_FIX_PC_FILE
>> +$(SED) "s at toolsdir=.*@toolsdir=$(STAGING_DIR)/usr/bin at g" \
>> + $(STAGING_DIR)/usr/lib/pkgconfig/glib-2.0.pc
>
> This kind of replacement with STAGING_DIR is a bit annoying for the
> upcoming per-package stuff. Options that I see:
Why is it annoying? It will point to libglib2's staging dir, but that's fine,
isn't it?
>
> (1) Add 'bindir' to the list of pkg-config variables that should be
> sysroot-prefixed. Works, but impact unknown.
With this option, the patch is not even needed!
Unfortunately, it might result in runtime breakage too... if some .pc's bindir
is used to set the path to some executable... Like
CFLAGS += -DBASH_PATH=`pkg-config bash --variable=bindir`/bash
> (2) Add 'toolsdir' to the list of pkg-config variables that should be
> sysroot-prefixed. Works, but impact unknown.
Something similar was in fact my plan, that in the pkg-config wrapper we add
--define-variable=toolsdir=$STAGING_DIR
Regards,
Arnout
>
> (3) Make toolsdir=${libdir}/../bin. Works, but ugly.
>
> I don't have a good opinion on what is the best choice here. Let's see
> what Arnout says.
>
> Thomas
>
prev parent reply other threads:[~2019-02-05 20:06 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-02-05 18:56 [Buildroot] [PATCH v2 1/1] libglib2: bump to 2.58.3 aduskett at gmail.com
2019-02-05 19:12 ` Baruch Siach
2019-02-05 19:29 ` Thomas Petazzoni
2019-02-05 20:06 ` Arnout Vandecappelle [this message]
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=45ddc4a4-b196-ad26-b96a-e794f1c0b720@mind.be \
--to=arnout@mind.be \
--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.