diff mbox

[1/2] package/wireshark: Fix libpcap detection

Message ID 5676CDEE.10206@mind.be
State Not Applicable
Headers show

Commit Message

Arnout Vandecappelle Dec. 20, 2015, 3:49 p.m. UTC
On 20-12-15 13:49, Yann E. MORIN wrote:
> Arnout, All,
> 
> On 2015-12-13 21:59 +0100, Arnout Vandecappelle spake thusly:
>> On 13-12-15 10:16, Bernd Kuhls wrote:
>>> To reproduce the build error I had to install libpcap0.8-dev on my host
>>> system, then wireshark configure picks up
>>>
>>> checking for pcap-config... /usr/bin/pcap-config
>>
>>  To fundamentally avoid this type of issue (we have a bunch of fixes like this),
>> I think we should add an additional directory that is put in the _beginning_ of
>> the path in TARGET_MAKE_ENV. This directory could then be populated through the
>> _CONFIG_SCRIPTS mechanism.
>>
>>  What do the others think?
> 
> I'v estarted having a look at your suggestion. The basic idea is
> relatively trivial to do, and I now have a FOO_CONFIG_DIR location
> where I put those scripts.
> 
> However, I'm not facing a wall:

 I guess you _are_ facing a wall :-)

> we use the same PATH for both the target
> and the host packages, set in BR_PATH. But of course, we do not want the
> host variants to find those foo-config scripts, since they are for the
> target; we really want host packages to find the host variants, whether
> the ones we install as part of our host packages, or the ones from the
> system.
> 
> So, we'd need to split the PATH for host and target variants.
> 
> I wonder if that would be acceptable.

 They used to be, but since they were identical, Samuel factored them away in
b989976.

> 
>>  It will be a bit of work to revert all these fixes again :-)
> 
> Indeed. I've already tried to hunt down all our "fixes" for this, and I
> have identified two cases:
> 
>   - packages already accept a FOO_CONFIG environement variable; for
>     those we just need to unset it;
> 
>   - we patch the package to replace a hard-coded cal to foo-config with
>     a construct like ${FOO_CONFIG:-foo-config}, for those, we need to
>     alse unpatch the package.
> 
> My grep-fuu must still be asleep today, since I could only identify wine
> in the second category, although I'm pretty sure we have at least a few
> other packages that we do patch for that.

git grep \\-config -- \*.patch

 Lot's of false positives though.


> The packages in the first category are reltively rare: only about 50 of
> them I could identify, so it should be pretty easy to fix.

 I was more concerned with the fixes like the one that was added by this patch:
git grep '\--with-.*=\$(STAGING_DIR)'


 Regards,
 Arnout


> 
> I'll work on this a bit mor elater today...
> 
> Regards,
> Yann E. MORIN.
>

Comments

Yann E. MORIN Dec. 21, 2015, 12:26 p.m. UTC | #1
Arnout, All,

On 2015-12-20 16:49 +0100, Arnout Vandecappelle spake thusly:
> On 20-12-15 13:49, Yann E. MORIN wrote:
> > On 2015-12-13 21:59 +0100, Arnout Vandecappelle spake thusly:
[--SNIP--]
> >>  To fundamentally avoid this type of issue (we have a bunch of fixes like this),
> >> I think we should add an additional directory that is put in the _beginning_ of
> >> the path in TARGET_MAKE_ENV. This directory could then be populated through the
> >> _CONFIG_SCRIPTS mechanism.
> >>
> >>  What do the others think?
> > 
> > I'v estarted having a look at your suggestion. The basic idea is
> > relatively trivial to do, and I now have a FOO_CONFIG_DIR location
> > where I put those scripts.
> > However, I'm not facing a wall:
>  I guess you _are_ facing a wall :-)

s/not/now/ :-)

> > So, we'd need to split the PATH for host and target variants.
> > I wonder if that would be acceptable.
>  They used to be, but since they were identical, Samuel factored them away in
> b989976.

Ah, thianks for the sha1, I was looking for it earlier.

[--SNIP--]
> > My grep-fuu must still be asleep today, since I could only identify wine
> > in the second category, although I'm pretty sure we have at least a few
> > other packages that we do patch for that.
> git grep \\-config -- \*.patch
>  Lot's of false positives though.

I can start with that.

> > The packages in the first category are reltively rare: only about 50 of
> > them I could identify, so it should be pretty easy to fix.
> 
>  I was more concerned with the fixes like the one that was added by this patch:
> diff --git a/package/wireshark/wireshark.mk b/package/wireshark/wireshark.mk
> index 534131b..2b06699 100644
> --- a/package/wireshark/wireshark.mk
> +++ b/package/wireshark/wireshark.mk
> @@ -24,6 +24,7 @@ WIRESHARK_CONF_OPTS = \
>  	--enable-static=no \
>  	--with-libsmi=no \
>  	--with-lua=no \
> +	--with-pcap=$(STAGING_DIR)/usr \
>  	--includedir=$(STAGING_DIR)/usr/include
> 
>  Another grep which turns up lots of false positives:
> git grep '\--with-.*=\$(STAGING_DIR)'

Yep, we can hunt them one by one as time passes...

Thanks!

Regards,
Yann E. MORIN.
diff mbox

Patch

diff --git a/package/wireshark/wireshark.mk b/package/wireshark/wireshark.mk
index 534131b..2b06699 100644
--- a/package/wireshark/wireshark.mk
+++ b/package/wireshark/wireshark.mk
@@ -24,6 +24,7 @@  WIRESHARK_CONF_OPTS = \
 	--enable-static=no \
 	--with-libsmi=no \
 	--with-lua=no \
+	--with-pcap=$(STAGING_DIR)/usr \
 	--includedir=$(STAGING_DIR)/usr/include

 Another grep which turns up lots of false positives: