All of lore.kernel.org
 help / color / mirror / Atom feed
From: Nathaniel Roach <nroach44@gmail.com>
To: buildroot@busybox.net
Subject: [Buildroot] [PATCH] bandwidthd: fix static build
Date: Sun, 05 Oct 2014 21:01:43 +0800	[thread overview]
Message-ID: <54314137.7020007@gmail.com> (raw)
In-Reply-To: <20141005144043.7b3aaac0@free-electrons.com>

On 05/10/14 20:40, Thomas Petazzoni wrote:
> Baruch, Nathaniel,
> 
> On Sun, 5 Oct 2014 07:50:37 +0300, Baruch Siach wrote:
> 
>>> Hi Baruch, I didn't end up using pcap-config, but could you check git
>>> version 4b07a0b3d3a280cdde582060cb29f3333ba4bf6e for me? It seems to
>>> work in the config you pasted above and I haven't had any issues in my
>>> other tests.
>>
>> I can confirm that upgrading bandwidthd to 
>> 4b07a0b3d3a280cdde582060cb29f3333ba4bf6e fixes the build of the config above. 
>> I still think that holding the complete knowledge of all your indirect 
>> dependencies, mandatory and optional, is not robust. A better future proof 
>> solution IMO is to use tools like pkg-config (or pcap-config in the case of 
>> libpcap) to list all dependencies that are in actual use for this specific 
>> build. But this is your call as upstream.
> 
> I definitely agree with Baruch here. Using pkg-config is much more
> robust, as it figures out the indirect dependencies automatically,
> without hardcoding them in bandwidthd and/or Buildroot.
> 
> However, Baruch patch doesn't seem to be fully correct: it does both a
> PKG_CHECK_MODULES on libpng, and an AC_CHECK_LIB, which seems a bit
> redundant.
> 
> Therefore, Nathaniel, since you're now the upstream developer, could
> you make the necessary changes in configure.ac to use pkg-config
> instead, and then send a patch updating Buildroot to a new version of
> bandwidthd ?
> 
> In the mean time, I'll mark:
> 
>   http://patchwork.ozlabs.org/patch/395809/
>   http://patchwork.ozlabs.org/patch/381899/
> 
> as 'Changes requested'.
> 
> Thanks,
> 
> Thomas
> 

Thomas, Baruch:

Yeah, I'm starting to lean that way too. Although I was a little
hesitant adding another build dependency, I now realise that it's
probably getting built anyway, and the version that's currently up on
github was more a case of "getting it to work".

I've had a look at pcap-config and it doesn't seem to do -lpthreads (or
from what I could see anything useful in this case), so I'll likely
adapt Baruch's original patch into upstream for both lpcap and lpng.

It might take me a few days as my study load has increased, but I'll get
it done.

Thanks,

Nathaniel.

  reply	other threads:[~2014-10-05 13:01 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-10-02  6:49 [Buildroot] [PATCH] bandwidthd: fix static build Baruch Siach
     [not found] ` <542CFECE.9020103@gmail.com>
2014-10-02  7:52   ` Baruch Siach
2014-10-02  7:56     ` Nathaniel Roach
2014-10-02  7:58       ` Baruch Siach
2014-10-02  8:24         ` Nathaniel Roach
2014-10-02  8:33           ` Baruch Siach
2014-10-03  6:35             ` Nathaniel Roach
2014-10-05  4:50               ` Baruch Siach
2014-10-05 12:40                 ` Thomas Petazzoni
2014-10-05 13:01                   ` Nathaniel Roach [this message]
2014-10-05 13:12                     ` 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=54314137.7020007@gmail.com \
    --to=nroach44@gmail.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.