[Buildroot] [PATCH 1/1] ncurses: generate libtermcap

[Buildroot] [PATCH 1/1] ncurses: generate libtermcap

[Pascal Mazon]

Hello,

I haven't had a feedback to my last answer on the subject of libtermcap 
within the ncurses package, therefore I'd like to address the issue again.

Indeed, I would prefer to have a solution upstream, rather than keeping 
a local patch.

Thank you,

Date: Mon, 27 Apr 2015 10:11:07 +0200
From: Pascal Mazon <pascal.mazon@6wind.com>
To: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Cc: buildroot at buildroot.org
Subject: Re: [Buildroot] [PATCH 1/1] ncurses: generate libtermcap
Message-ID: <553DEF1B.3070807@6wind.com>
Content-Type: text/plain; charset=windows-1252; format=flowed

On 04/24/2015 04:18 PM, Thomas Petazzoni wrote:
  > 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.
  >
  > Which external toolchains are in this situation?

I encountered this with a Cavium OCTEON toolchain.

  >
  >> 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,
  >
  > I think this should probably not be done by the ncurses package, but as
  > a post-install hook of the external toolchain.

But in that case, would it still be possible not to delete libtermcap.a
if ncurses is not selected (to still be able to link against it)?

I put this patch in the ncurses package, as the issue arises only when
it is enabled, and it is intimately associated with ncurses selection.
I've been thinking that as ncurses provides libtermcap and it is the
implementation of choice, it ought to be done there.

I've looked on Debian, the termcap.h and libtermcap.so are provided in
the libncurses-dev package itself, too.

  >
  > Thomas
  >

-- Pascal Mazon www.6wind.com

-- 
Pascal Mazon
www.6wind.com

[Buildroot] [PATCH 1/1] ncurses: generate libtermcap

[Pascal Mazon]

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>
---
 package/ncurses/ncurses.mk | 15 +++++++++++++++
 1 file changed, 15 insertions(+)

diff --git a/package/ncurses/ncurses.mk b/package/ncurses/ncurses.mk
index 8368c690b606..f4b03ed5db15 100644
--- a/package/ncurses/ncurses.mk
+++ b/package/ncurses/ncurses.mk
@@ -112,6 +112,20 @@ ifneq ($(BR2_ENABLE_DEBUG),y)
 NCURSES_CONF_OPTS += --without-debug
 endif
 
+define NCURSES_LINK_LIBTERMCAP
+	ln -sf libncurses$(NCURSES_LIB_SUFFIX).$(2) $(1)/usr/lib/libtermcap.$(2)
+endef
+
+NCURSES_LINK_STAGING_TERMCAP = \
+	rm -f $(STAGING_DIR)/usr/lib/libtermcap.*; \
+	$(if $(BR2_STATIC_LIBS)$(BR2_SHARED_STATIC_LIBS),$(call NCURSES_LINK_LIBTERMCAP,$(STAGING_DIR),a);) \
+	$(if $(BR2_SHARED_LIBS)$(BR2_SHARED_STATIC_LIBS),$(call NCURSES_LINK_LIBTERMCAP,$(STAGING_DIR),so))
+NCURSES_LINK_TARGET_TERMCAP = \
+	$(if $(BR2_STATIC_LIBS)$(BR2_SHARED_STATIC_LIBS),$(call NCURSES_LINK_LIBTERMCAP,$(TARGET_DIR),a);) \
+	$(if $(BR2_SHARED_LIBS)$(BR2_SHARED_STATIC_LIBS),$(call NCURSES_LINK_LIBTERMCAP,$(TARGET_DIR),so))
+
+NCURSES_POST_INSTALL_STAGING_HOOKS += NCURSES_LINK_STAGING_TERMCAP
+
 # ncurses breaks with parallel build, but takes quite a while to
 # build single threaded. Work around it similar to how Gentoo does
 define NCURSES_BUILD_CMDS
@@ -143,6 +157,7 @@ define NCURSES_INSTALL_TARGET_CMDS
 	mkdir -p $(TARGET_DIR)/usr/lib
 	$(NCURSES_INSTALL_TARGET_LIBS)
 	$(NCURSES_LINK_TARGET_LIBS)
+	$(NCURSES_LINK_TARGET_TERMCAP)
 	$(NCURSES_INSTALL_TARGET_PROGS)
 	ln -snf /usr/share/terminfo $(TARGET_DIR)/usr/lib/terminfo
 	mkdir -p $(TARGET_DIR)/usr/share/terminfo/x
-- 
2.3.0.rc0

[Buildroot] [PATCH 1/1] ncurses: generate libtermcap

[Thomas Petazzoni]

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.

Which external toolchains are in this situation?

> 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,

I think this should probably not be done by the ncurses package, but as
a post-install hook of the external toolchain.

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

[Buildroot] [PATCH 1/1] ncurses: generate libtermcap

[Pascal Mazon]

On 04/24/2015 04:18 PM, Thomas Petazzoni wrote:
 > 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.
 >
 > Which external toolchains are in this situation?

I encountered this with a Cavium OCTEON toolchain.

 >
 >> 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,
 >
 > I think this should probably not be done by the ncurses package, but as
 > a post-install hook of the external toolchain.

But in that case, would it still be possible not to delete libtermcap.a
if ncurses is not selected (to still be able to link against it)?

I put this patch in the ncurses package, as the issue arises only when
it is enabled, and it is intimately associated with ncurses selection.
I've been thinking that as ncurses provides libtermcap and it is the
implementation of choice, it ought to be done there.

I've looked on Debian, the termcap.h and libtermcap.so are provided in
the libncurses-dev package itself, too.

 >
 > Thomas
 >

-- 
Pascal Mazon
www.6wind.com

[Buildroot] [PATCH 1/1] ncurses: generate libtermcap

[Thomas Petazzoni]

Thomas,

Can you have a look at the patch below? According to Pascal, the
submitter, it's related to an issue that appears with Cavium Octeon
toolchains which I believe you have access to. Apparently, the
toolchain ships with a libtermcap.a library, which causes some
troubles down the road.

Thanks!

Thomas

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>
> ---
>  package/ncurses/ncurses.mk | 15 +++++++++++++++
>  1 file changed, 15 insertions(+)
> 
> diff --git a/package/ncurses/ncurses.mk b/package/ncurses/ncurses.mk
> index 8368c690b606..f4b03ed5db15 100644
> --- a/package/ncurses/ncurses.mk
> +++ b/package/ncurses/ncurses.mk
> @@ -112,6 +112,20 @@ ifneq ($(BR2_ENABLE_DEBUG),y)
>  NCURSES_CONF_OPTS += --without-debug
>  endif
>  
> +define NCURSES_LINK_LIBTERMCAP
> +	ln -sf libncurses$(NCURSES_LIB_SUFFIX).$(2) $(1)/usr/lib/libtermcap.$(2)
> +endef
> +
> +NCURSES_LINK_STAGING_TERMCAP = \
> +	rm -f $(STAGING_DIR)/usr/lib/libtermcap.*; \
> +	$(if $(BR2_STATIC_LIBS)$(BR2_SHARED_STATIC_LIBS),$(call NCURSES_LINK_LIBTERMCAP,$(STAGING_DIR),a);) \
> +	$(if $(BR2_SHARED_LIBS)$(BR2_SHARED_STATIC_LIBS),$(call NCURSES_LINK_LIBTERMCAP,$(STAGING_DIR),so))
> +NCURSES_LINK_TARGET_TERMCAP = \
> +	$(if $(BR2_STATIC_LIBS)$(BR2_SHARED_STATIC_LIBS),$(call NCURSES_LINK_LIBTERMCAP,$(TARGET_DIR),a);) \
> +	$(if $(BR2_SHARED_LIBS)$(BR2_SHARED_STATIC_LIBS),$(call NCURSES_LINK_LIBTERMCAP,$(TARGET_DIR),so))
> +
> +NCURSES_POST_INSTALL_STAGING_HOOKS += NCURSES_LINK_STAGING_TERMCAP
> +
>  # ncurses breaks with parallel build, but takes quite a while to
>  # build single threaded. Work around it similar to how Gentoo does
>  define NCURSES_BUILD_CMDS
> @@ -143,6 +157,7 @@ define NCURSES_INSTALL_TARGET_CMDS
>  	mkdir -p $(TARGET_DIR)/usr/lib
>  	$(NCURSES_INSTALL_TARGET_LIBS)
>  	$(NCURSES_LINK_TARGET_LIBS)
> +	$(NCURSES_LINK_TARGET_TERMCAP)
>  	$(NCURSES_INSTALL_TARGET_PROGS)
>  	ln -snf /usr/share/terminfo $(TARGET_DIR)/usr/lib/terminfo
>  	mkdir -p $(TARGET_DIR)/usr/share/terminfo/x



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

[Buildroot] [PATCH 1/1] ncurses: generate libtermcap

[Thomas Petazzoni]

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

[Buildroot] [PATCH 1/1] ncurses: generate libtermcap

[Pascal Mazon]

On 11/30/2015 11:30 PM, Thomas Petazzoni wrote:
 > 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
 >

I understand buildroot's point of view.
Indeed, it does not look like the best solution to hack in packages for 
a problem from the toolchain.

I will try your suggestion.
Maybe we can modify copy_toolchain_sysroot in toolchain/helpers.mk to 
add a custom "--exclude" when rsync-ing (with values taken from an newly 
added option)?

Best regards,

-- 
Pascal Mazon
www.6wind.com

[Buildroot] [PATCH 1/1] ncurses: generate libtermcap

[Yann E. MORIN]

Pascal, All,

On 2015-12-02 11:39 +0100, Pascal Mazon spake thusly:
> On 11/30/2015 11:30 PM, Thomas Petazzoni wrote:
> > 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
> >
> 
> I understand buildroot's point of view.
> Indeed, it does not look like the best solution to hack in packages for a
> problem from the toolchain.
> 
> I will try your suggestion.
> Maybe we can modify copy_toolchain_sysroot in toolchain/helpers.mk to add a
> custom "--exclude" when rsync-ing (with values taken from an newly added
> option)?

Like a patch I submitted a while ago and was rejected?
    https://patchwork.ozlabs.org/patch/535404/

Thomas, Peter, it seems we now have a valid use-case for that patch.
Should I respin it, now?

Regards,
Yann E. MORIN.

-- 
.-----------------.--------------------.------------------.--------------------.
|  Yann E. MORIN  | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: |
| +33 662 376 056 | Software  Designer | \ / CAMPAIGN     |  ___               |
| +33 223 225 172 `------------.-------:  X  AGAINST      |  \e/  There is no  |
| http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL    |   v   conspiracy.  |
'------------------------------^-------^------------------^--------------------'