Buildroot Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
To: buildroot@busybox.net
Subject: [Buildroot] [PATCH 1/1] ncurses: generate libtermcap
Date: Mon, 30 Nov 2015 23:30:49 +0100	[thread overview]
Message-ID: <20151130233049.3ad42bd1@free-electrons.com> (raw)
In-Reply-To: <1429880066-7743-1-git-send-email-pascal.mazon@6wind.com>

Dear Pascal Mazon,

On Fri, 24 Apr 2015 14:54:26 +0200, Pascal Mazon wrote:
> There is no libtermcap package in buildroot, but ncurses implements termcap
> natively. Furthermore, ncurses already provides the termcap.h header file.
> 
> With this patch, we fix an issue encountered with some external toolchains
> that include a libtermcap.a (typically the GNU libtermcap version) in their
> sysroot folder.
> Bash, for instance, would be linking with this libtermcap while using
> headers from ncurses.
> 
> In order to be consistent, let's make sure there is only the ncurses'
> termcap library. To that effect, we:
> - remove any libtermcap.* in the staging dir,
> - install a link to libncurses static and/or shared in staging and target
>   dirs.
> 
> Signed-off-by: Pascal Mazon <pascal.mazon@6wind.com>

We finally took a bit of time on IRC today to discuss your patch. From
our point of view, the fact that your toolchain provides libtermcap.a
is a bug of the toolchain. From Buildroot's point of view, a toolchain
should not provide in its sysroot anything but the C library and its
headers, and the kernel headers.

If we start doing hacks in packages to cope with toolchain sysroot
already shipped with some libraries, it's going to be an endless fight
against those toolchains. You have the problem with libtermcap.a, but
the next person will have it with libz.a, and then lib<something>, and
again.

Our suggestion is that you fix your toolchain either by asking your
toolchain vendor, or by doing a quick hack to remove libtermcap.a
before using the toolchain with Buildroot. If you add this toolchain as
a known Buildroot profile, you can even automate this and make it part
of the build process.

Best regards,

Thomas
-- 
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com

  parent reply	other threads:[~2015-11-30 22:30 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-04-24 12:54 [Buildroot] [PATCH 1/1] ncurses: generate libtermcap Pascal Mazon
2015-04-24 14:18 ` Thomas Petazzoni
2015-04-27  8:11   ` Pascal Mazon
2015-07-19  9:19 ` Thomas Petazzoni
2015-11-30 22:30 ` Thomas Petazzoni [this message]
2015-12-02 10:39   ` Pascal Mazon
2015-12-05 17:39     ` Yann E. MORIN
  -- strict thread matches above, loose matches on Subject: below --
2015-05-20  9:11 Pascal Mazon

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=20151130233049.3ad42bd1@free-electrons.com \
    --to=thomas.petazzoni@free-electrons.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox