ncurses: generate libtermcap

PATCH New Pascal Mazon 3 participants 7 messages Apr 24, 2015 – Dec 5, 2015

Share & tools

Pascal Mazon

author

2015-04-24 12:54 UTC #0 lore raw

PATCH 1/1 ncurses: generate libtermcap

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 <[email protected]>

---
 package/ncurses/ncurses.mk | 15 +++++++++++++++
 1 file changed, 15 insertions(+)

package/ncurses/ncurses.mk +15 -0

index 8368c690b606..f4b03ed5db15 100644
@@ -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

Signature · 1 line

2.3.0.rc0

Thomas Petazzoni

2015-04-24 14:18 UTC #1 lore raw

PATCH 1/1 ncurses: generate libtermcap

Dear Pascal Mazon,

Quoted 6 lines · 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.

Which external toolchains are in this situation?

Quoted 6 lines

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

Signature · 3 lines

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

Pascal Mazon

author

2015-04-27 08:11 UTC #2 lore raw

PATCH 1/1 ncurses: generate libtermcap

Quoted 4 lines · Thomas Petazzoni

Dear Pascal Mazon,
Quoted 1 line · Pascal Mazon
There is no libtermcap package in buildroot, but ncurses implements

termcap

Quoted 1 line

Quoted 1 line
natively. Furthermore, ncurses already provides the termcap.h header

file.

Quoted 2 lines

Quoted 2 lines
With this patch, we fix an issue encountered with some external

toolchains

Quoted 1 line

Quoted 1 line
that include a libtermcap.a (typically the GNU libtermcap version)

in their

Quoted 3 lines

Quoted 1 line
sysroot folder.
Which external toolchains are in this situation?

I encountered this with a Cavium OCTEON toolchain.

Quoted 10 lines

Quoted 7 lines
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.

Quoted 3 lines

Thomas

Signature · 2 lines

Pascal Mazon
www.6wind.com

Thomas Petazzoni

2015-07-19 09:19 UTC #3 lore raw

PATCH 1/1 ncurses: generate libtermcap

In reply to Pascal Mazon

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

Quoted 53 lines · 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 <[email protected]>
---
 package/ncurses/ncurses.mk | 15 +++++++++++++++
 1 file changed, 15 insertions(+)
package/ncurses/ncurses.mk +15 -0
index 8368c690b606..f4b03ed5db15 100644
@@ -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

Signature · 3 lines

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

Thomas Petazzoni

2015-11-30 22:30 UTC #4 lore raw

PATCH 1/1 ncurses: generate libtermcap

In reply to Pascal Mazon

Dear Pascal Mazon,

Quoted 9 lines · 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.

Quoted 7 lines

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 <[email protected]>

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

Signature · 3 lines

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

Pascal Mazon

author

2015-12-02 10:39 UTC #5 lore raw

PATCH 1/1 ncurses: generate libtermcap

Quoted 4 lines · Thomas Petazzoni

Dear Pascal Mazon,
Quoted 1 line · Pascal Mazon
There is no libtermcap package in buildroot, but ncurses implements

termcap

Quoted 1 line

Quoted 1 line
natively. Furthermore, ncurses already provides the termcap.h header

file.

Quoted 2 lines

Quoted 2 lines
With this patch, we fix an issue encountered with some external

toolchains

Quoted 1 line

Quoted 1 line
that include a libtermcap.a (typically the GNU libtermcap version)

in their

Quoted 8 lines

Quoted 8 lines
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

Quoted 22 lines

Quoted 3 lines
dirs.
Signed-off-by Pascal Mazon <[email protected]>
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.

Quoted 4 lines

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,

Signature · 2 lines

Pascal Mazon
www.6wind.com

Yann E. MORIN

2015-12-05 17:39 UTC #6 lore raw

PATCH 1/1 ncurses: generate libtermcap

Pascal, All,

On 2015-12-02 11:39 +0100, Pascal Mazon spake thusly:

Quoted 46 lines · Thomas Petazzoni

Quoted 2 lines · Pascal Mazon
Quoted 1 line
There is no libtermcap package in buildroot, but ncurses implements
termcap
Quoted 1 line
Quoted 1 line
natively. Furthermore, ncurses already provides the termcap.h header
file.
Quoted 2 lines
Quoted 2 lines
With this patch, we fix an issue encountered with some external
toolchains
Quoted 1 line
Quoted 1 line
that include a libtermcap.a (typically the GNU libtermcap version) in
their
Quoted 30 lines
Quoted 11 lines
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 <[email protected]>
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.
Quoted 4 lines
Best regards,
Thomas

Quoted 8 lines

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.

Signature · 6 lines

.-----------------.--------------------.------------------.--------------------.
|  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.  |
'------------------------------^-------^------------------^--------------------'