ncurses: drop the compatible option

The following changes since commit 68c7113a746694e25df2ac5d86171ed96b7c2e94:

poky.conf: Delete BB_SIGNATURE_HANDLER settings (2016-01-19 23:02:01 +0000)

are available in the git repository at:

git://git.openembedded.org/openembedded-core-contrib dengke/ncurses_drop_compatible_option
http://cgit.openembedded.org/cgit.cgi/openembedded-core-contrib/log/?h=dengke/ncurses_drop_compatible_option

Dengke Du (1):
ncurses: drop the compatible option

 meta/recipes-core/ncurses/ncurses.inc    | 10 +++++-----
 meta/recipes-core/ncurses/ncurses_6.0.bb |  1 -
 2 files changed, 5 insertions(+), 6 deletions(-)

1.9.1

drop the compatible option --with-abi-version=5

---
 meta/recipes-core/ncurses/ncurses.inc    | 10 +++++-----
 meta/recipes-core/ncurses/ncurses_6.0.bb |  1 -
 2 files changed, 5 insertions(+), 6 deletions(-)

index fbe74d5..0ebf8d5 100644
@@ -7,7 +7,7 @@ SECTION = "libs"
 DEPENDS = "ncurses-native"
 DEPENDS_class-native = ""
 
-BINCONFIG = "${bindir}/ncurses5-config ${bindir}/ncursesw5-config"
+BINCONFIG = "${bindir}/ncurses6-config ${bindir}/ncursesw6-config"
 
 inherit autotools binconfig-disabled multilib_header pkgconfig
 

@@ -205,7 +205,7 @@ do_install() {
                 test -h $f || continue
                 rm -f $f
                 echo '/* GNU ld script */'  >$f
-                echo "INPUT($i.so.5 AS_NEEDED(-ltinfo))" >>$f
+                echo "INPUT($i.so.6 AS_NEEDED(-ltinfo))" >>$f
         done
 
         # Make sure that libcurses is linked so that it gets -ltinfo

@@ -231,7 +231,7 @@ do_install() {
             # Use lnr to ensure this is a relative link despite absolute paths
             # (as we can't know the relationship between base_libdir and libdir).
             # At some point we can rely on coreutils 8.16 which has ln -r.
-            lnr ${D}${base_libdir}/libtinfo.so.5 ${D}${libdir}/libtinfo.so
+            lnr ${D}${base_libdir}/libtinfo.so.6 ${D}${libdir}/libtinfo.so
         fi
         if [ -d "${D}${includedir}/ncurses" ]; then
             for f in `find ${D}${includedir}/ncurses -name "*.h"`

@@ -271,8 +271,8 @@ PACKAGES += " \
 FILES_${PN} = "\
   ${bindir}/tput \
   ${bindir}/tset \
-  ${bindir}/ncurses5-config \
-  ${bindir}/ncursesw5-config \
+  ${bindir}/ncurses6-config \
+  ${bindir}/ncursesw6-config \
   ${datadir}/tabset \
 "
 

index 8587287..ea45ea7 100644
@@ -8,4 +8,3 @@ SRC_URI += "file://tic-hang.patch \
 # commit id corresponds to the above listed REVISION
 SRCREV = "c6b034b4d69f8c9092c2a1b5d5bb718282b2a522"
 S = "${WORKDIR}/git"
-EXTRA_OECONF += "--with-abi-version=5"

1.9.1

This says what the patch does, but not why.

Why should we do this? Does any of our software depend on the v5 ABI? How did you test this?

Cheers,

Richard

I had talked with Dengke, we have upgraded ncurses to 6, so remove --with-abi-version=5 seems better. He had tested world and sdk build based on oe-core. He will test it based on meta-openembedded.

// Robert

we need to ensure that all apps using ncurses are able to work with new APIs if we drop compatibility.
may be have ncurses5 package still around to provide backward compatibility.

According to the ncurses 6.0 release notes (the site is at "https://www.gnu.org/software/ncurses/"), the intent of the release is to provide a new stable ABI, which is binary-incompatible with ncurses 5, but it can still be configured to support the ncurses5. Because this release introduces symbol-versioning. The symbol-versioning allows the developers of a library tomark each public sysmbol(both data and functions) with an identifier denoting the library name and the version for which it was built. By doing this , users ofthe library have a way to help ensure that applications do not accidentally load an imcompatible library. In addition, private sysmbols can be hidden entirely.
------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
When I first release the patch 5.9 -> 6.0 with the option --with-abi-version=5, I want to be compatible with the existing system, so I do the following test:

$bitbake world core-image-sato-sdk

tested it on the qemuarm, qemux86, qemux86-64 with multilib (oe-core), and no error happened .

-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
When I second release the patch "drop the compatible option --with-abi-version=5", because I want to introduces the feature symbol-versioning, so I droped the option --with-abi-version=5 , and I do the following test:

$bitbake world core-image-sato-sdk

tested it on the qemuarm, qemux86, qemux86-64 with multilib (oe-core), and no error happened.

Today, Robert let me test it on the following layers:

/meta-openembedded/meta-oe
/meta-openembedded/meta-networking
/meta-openembedded/meta-meta-webserver

so I add the layers to my build and run the following commands:

$bitbake world

It reported the following error:

Summary: 15 tasks failed:
/buildarea/raid0/ddu/poky/meta-openembedded/meta-oe/recipes-graphics/takao-fonts/takao-fonts_003.03.01.bb, do_fetch /buildarea/raid0/ddu/poky/meta-openembedded/meta-oe/recipes-support/portaudio/portaudio-v19_svn.bb, do_fetch /buildarea/raid0/ddu/poky/meta-openembedded/meta-oe/recipes-gnome/gtkhtml2/gtkhtml2_svn.bb, do_fetch /buildarea/raid0/ddu/poky/meta-openembedded/meta-python/recipes-devtools/python/python-cryptography-vectors_1.1.bb, do_fetch /buildarea/raid0/ddu/poky/meta-openembedded/meta-networking/recipes-support/geoip/geoip_1.6.6.bb, do_fetch /buildarea/raid0/ddu/poky/meta-openembedded/meta-networking/recipes-connectivity/ufw/ufw_0.33.bb, do_fetch /buildarea/raid0/ddu/poky/meta-openembedded/meta-oe/recipes-support/ctapi-common/ctapi-common_1.1-11.bb, do_fetch /buildarea/raid0/ddu/poky/meta-openembedded/meta-python/recipes-devtools/python/python-decorator_4.0.2.bb, do_fetch /buildarea/raid0/ddu/poky/meta-openembedded/meta-python/recipes-connectivity/python-thrift/python-thrift_0.9.2.bb, do_fetch /buildarea/raid0/ddu/poky/meta-openembedded/meta-python/recipes-devtools/python/python-sqlalchemy_0.7.9.bb, do_fetch /buildarea/raid0/ddu/poky/meta-openembedded/meta-webserver/recipes-httpd/cherokee/cherokee_1.2.98.bb, do_fetch /buildarea/raid0/ddu/poky/meta-openembedded/meta-oe/recipes-graphics/ttf-fonts/ttf-mplus_027.bb, do_fetch virtual:native:/buildarea/raid0/ddu/poky/meta-openembedded/meta-oe/recipes-support/uim/uim_1.8.6.bb, do_install /buildarea/raid0/ddu/poky/meta-openembedded/meta-oe/recipes-connectivity/umip/umip_1.0.bb, do_compile /buildarea/raid0/ddu/poky/meta-openembedded/meta-oe/recipes-graphics/x11vnc/x11vnc_0.9.13.bb, do_package_qa

It seems the umip was affect by the ncurses version change. So I went to the log.do_compile, the log file say:

fatal error: gram.h : No such file or directory
compilation terminated

So I think the ncurses version change didn't affect the whole system. Then I release the patch "ncurses: drop the compatible option"
-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

According to the ncurses 6.0 release notes (the site is at "https://www.gnu.org/software/ncurses/"), the intent of the release is to provide a new stable ABI, which is binary-incompatible with ncurses 5, but it can still be configured to support the ncurses5. Because this release introduces symbol-versioning. The symbol-versioning allows the developers of a library to mark each public sysmbol(both data and functions) with an identifier denoting the library name and the version for which it was built. By doing this , users of the library have a way to help ensure that applications do not accidentally load an imcompatible library. In addition, private sysmbols can be hidden entirely.
------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
When I first release the patch 5.9 -> 6.0 with the option --with-abi-version=5, I want to be compatible with the existing system, so I do the following test:

$bitbake world core-image-sato-sdk

tested it on the qemuarm, qemux86, qemux86-64 with multilib (oe-core), and no error happened .

-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
When I second release the patch "drop the compatible option --with-abi-version=5", because I want to introduces the feature symbol-versioning, so I droped the option --with-abi-version=5 , and I do the following test:

$bitbake world core-image-sato-sdk

tested it on the qemuarm, qemux86, qemux86-64 with multilib (oe-core), and no error happened.

Today, Robert let me test it on the following layers:

/meta-openembedded/meta-oe
/meta-openembedded/meta-networking
/meta-openembedded/meta-meta-webserver

so I add the layers to my build and run the following commands:

$bitbake world

It reported the following error:

Summary: 15 tasks failed:
/buildarea/raid0/ddu/poky/meta-openembedded/meta-oe/recipes-graphics/takao-fonts/takao-fonts_003.03.01.bb, do_fetch /buildarea/raid0/ddu/poky/meta-openembedded/meta-oe/recipes-support/portaudio/portaudio-v19_svn.bb, do_fetch /buildarea/raid0/ddu/poky/meta-openembedded/meta-oe/recipes-gnome/gtkhtml2/gtkhtml2_svn.bb, do_fetch /buildarea/raid0/ddu/poky/meta-openembedded/meta-python/recipes-devtools/python/python-cryptography-vectors_1.1.bb, do_fetch /buildarea/raid0/ddu/poky/meta-openembedded/meta-networking/recipes-support/geoip/geoip_1.6.6.bb, do_fetch /buildarea/raid0/ddu/poky/meta-openembedded/meta-networking/recipes-connectivity/ufw/ufw_0.33.bb, do_fetch /buildarea/raid0/ddu/poky/meta-openembedded/meta-oe/recipes-support/ctapi-common/ctapi-common_1.1-11.bb, do_fetch /buildarea/raid0/ddu/poky/meta-openembedded/meta-python/recipes-devtools/python/python-decorator_4.0.2.bb, do_fetch /buildarea/raid0/ddu/poky/meta-openembedded/meta-python/recipes-connectivity/python-thrift/python-thrift_0.9.2.bb, do_fetch /buildarea/raid0/ddu/poky/meta-openembedded/meta-python/recipes-devtools/python/python-sqlalchemy_0.7.9.bb, do_fetch /buildarea/raid0/ddu/poky/meta-openembedded/meta-webserver/recipes-httpd/cherokee/cherokee_1.2.98.bb, do_fetch /buildarea/raid0/ddu/poky/meta-openembedded/meta-oe/recipes-graphics/ttf-fonts/ttf-mplus_027.bb, do_fetch virtual:native:/buildarea/raid0/ddu/poky/meta-openembedded/meta-oe/recipes-support/uim/uim_1.8.6.bb, do_install /buildarea/raid0/ddu/poky/meta-openembedded/meta-oe/recipes-connectivity/umip/umip_1.0.bb, do_compile /buildarea/raid0/ddu/poky/meta-openembedded/meta-oe/recipes-graphics/x11vnc/x11vnc_0.9.13.bb, do_package_qa

It seems the umip was affect by the ncurses version change. So I went to the log.do_compile, the log file say:

fatal error: gram.h : No such file or directory
compilation terminated

So I think the ncurses version change didn't affect the whole system. Then I release the patch "ncurses: drop the compatible option"
-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------