meta: use ln -rs instead of lnr

lnr is a script in oe-core that creates relative symlinks, with the same
behaviour as `ln --relative --symlink`.  It was added back in 2014[1] as
not all of the supported host distributions at the time shipped
coreutils 8.16, the first release with --relative.

However the oldest coreutils release in the supported distributions is
now 8.22 in CentOS 7, so lnr can be deprecated and users switched to ln.

[1] 6ae3b85eaffd1b0b6914422e8de7c1230723157d

(From OE-Core rev: 1ca455a98de4c713f58df0a537d4c982d256cd68)

Signed-off-by: Ross Burton <ross.burton@arm.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>

1 files changed, 2 insertions, 2 deletions

diff --git a/meta/recipes-core/ncurses/ncurses.inc b/meta/recipes-core/ncurses/ncurses.inc
index 64cce329aa..3f04545465 100644
--- a/meta/recipes-core/ncurses/ncurses.inc
+++ b/meta/recipes-core/ncurses/ncurses.inc
@@ -242,10 +242,10 @@ do_install() {
             mv ${D}${libdir}/libtinfo.so.* ${D}${base_libdir}
             rm ${D}${libdir}/libtinfo.so
 
-            # Use lnr to ensure this is a relative link despite absolute paths
+            # Use ln -rs 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
+            ln -rs ${D}${base_libdir}/libtinfo.so.5 ${D}${libdir}/libtinfo.so
         fi
         if [ -d "${D}${includedir}/ncurses" ]; then
             for f in `find ${D}${includedir}/ncurses -name "*.h"`