All of lore.kernel.org
 help / color / mirror / Atom feed
From: Arnout Vandecappelle <arnout@mind.be>
To: buildroot@busybox.net
Subject: [Buildroot] [git commit] ffmpeg: fix static linking build failure when using libavutil
Date: Tue, 29 Jan 2019 14:39:45 +0100	[thread overview]
Message-ID: <0535ae91-47fa-5a31-5ff6-7977c5bbbe8b@mind.be> (raw)
In-Reply-To: <5d3cbc8e-e846-65ed-6ef9-6c5f3dcf4933@micronovasrl.com>



On 29/01/2019 13:30, Giulio Benetti wrote:
> Hi Arnout,
> 
> Il 29/01/2019 10:03, Arnout Vandecappelle ha scritto:
>> ? Oopsie...
>>
>> On 29/01/2019 00:16, Arnout Vandecappelle (Essensium/Mind) wrote:
>>> commit:
>>> https://git.buildroot.net/buildroot/commit/?id=483db9908985d023b858c0b59d4016f9abb4b6f9
>>>
>>> branch: https://git.buildroot.net/buildroot/commit/?id=refs/heads/master
>>>
>>> If a package tries to static link with libavutil it fails due to the
>>> lack of libavutil private dependencies in libavutil.pc (-ldrm in this
>>> case).
>>>
>>> Add patch to:
>>> - Check if libdrm is present.
>>> - Add it to Libs.private: in libavutil.pc if present.
>>
>> ? I didn't want to push this one, it was just a test. The patch no longer applies
>> to ffmpeg 3.4.5 so this is causing autobuilder breakage. Therefore, I pushed a
>> revert commit.
> 
> I've forgot it there pending on patchwork after ffmpeg bump.

 I've marked it as Changes Requested now.

> 
>> ? Giulio, FYI, upstream has added an explicit $LIBDRM but not to Libs.Private, so
>> the static linking case still breaks for the same reason. The patch just needs
>> to be rebased (and sent upstream).
> 
> I've tried several times to discuss this on ffmpeg-devel:
> [1] http://ffmpeg.org/pipermail/ffmpeg-devel/2018-October/235269.html
> but they ignored my last patch:
> [2] http://ffmpeg.org/pipermail/ffmpeg-devel/2018-October/235417.html
> to fix the previous I've sent:
> [3] http://ffmpeg.org/pipermail/ffmpeg-devel/2018-October/235269.html
> 
> I can't understand why they don't want to upstream my last patch[2]...

 Same as everywhere: too many patches, too few reviewers. The reactions to v1
seemed to be positive. So if v2 still applies to current ffmpeg master, just
ping it; if it needs to be rebased, rebase it and resubmit.

 Regards,
 Arnout

> 
> Anyway I'm going to submit the last one for Buildroot asap.
> I'm going to reproduce it right now.
> 
> Best regards
> 

  reply	other threads:[~2019-01-29 13:39 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-01-28 23:16 [Buildroot] [git commit] ffmpeg: fix static linking build failure when using libavutil Arnout Vandecappelle
2019-01-29  9:03 ` Arnout Vandecappelle
2019-01-29 12:30   ` Giulio Benetti
2019-01-29 13:39     ` Arnout Vandecappelle [this message]
2019-01-29 17:02       ` Giulio Benetti
2019-01-30 16:01       ` [Buildroot] [PATCH] ffmpeg: improve linking avoiding -ldrm to be appended when -lavutil is linked Giulio Benetti
2019-04-03 21:24         ` Giulio Benetti

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=0535ae91-47fa-5a31-5ff6-7977c5bbbe8b@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.