[OE-core] [PATCH][RFC] coreutils: Upgrade to upstream version 8.17
Radu Moisan
radu.moisan at intel.com
Fri Aug 17 13:06:43 UTC 2012
The problem:
The new version of coreutils, adds use of canonicalize_file_name()
function defined in canonicalize.h The problem I encountered is at
compile time, the function is redefined to rpl_canonicalize_file_name by
means of a macro, and I get an undefined reference error.
//-- stdlib.in.h
#if @GNULIB_CANONICALIZE_FILE_NAME@
# if @REPLACE_CANONICALIZE_FILE_NAME@
# if !(defined __cplusplus && defined GNULIB_NAMESPACE)
# define canonicalize_file_name rpl_canonicalize_file_name
# endif
I've looked for REPLACE_CANONICALIZE_FILE_NAME and found out that is
being set in configure, which is generated from canonicalize.m4
# canonicalize.m4 serial 24
dnl Copyright (C) 2003-2007, 2009-2012 Free Software Foundation, Inc.
dnl This file is free software; the Free Software Foundation
dnl gives unlimited permission to copy and/or distribute it,
dnl with or without modifications, as long as this notice is preserved.
# Provides canonicalize_file_name and canonicalize_filename_mode, but does
# not provide or fix realpath.
AC_DEFUN([gl_FUNC_CANONICALIZE_FILENAME_MODE],
[
AC_REQUIRE([gl_USE_SYSTEM_EXTENSIONS])
AC_CHECK_FUNCS_ONCE([canonicalize_file_name])
AC_REQUIRE([gl_DOUBLE_SLASH_ROOT])
AC_REQUIRE([gl_FUNC_REALPATH_WORKS])
if test $ac_cv_func_canonicalize_file_name = no; then
HAVE_CANONICALIZE_FILE_NAME=0
elif test "$gl_cv_func_realpath_works" != yes; then
REPLACE_CANONICALIZE_FILE_NAME=1
fi
])
# Provides canonicalize_file_name and realpath.
AC_DEFUN([gl_CANONICALIZE_LGPL],
[
AC_REQUIRE([gl_STDLIB_H_DEFAULTS])
AC_REQUIRE([gl_CANONICALIZE_LGPL_SEPARATE])
if test $ac_cv_func_canonicalize_file_name = no; then
HAVE_CANONICALIZE_FILE_NAME=0
if test $ac_cv_func_realpath = no; then
HAVE_REALPATH=0
elif test "$gl_cv_func_realpath_works" != yes; then
REPLACE_REALPATH=1
fi
elif test "$gl_cv_func_realpath_works" != yes; then
REPLACE_CANONICALIZE_FILE_NAME=1
REPLACE_REALPATH=1
fi
])
Then I followed gl_cv_func_realpath_works and found it to be set to
"guessing yes"
# canonicalize.m4 serial 24
[case "$host_os" in
# Guess yes on glibc systems.
*-gnu*) gl_cv_func_realpath_works="guessing yes" ;;
# If we don't know, assume the worst.
*) gl_cv_func_realpath_works="guessing no" ;;
esac
Being set this way it looked to me like it was always assumed to be "no"
and thus assumed real path didn't work. In fact, I could not make a
logic for "guessing yes" and "quessing no" because to me it looks like
they are not verified against and thus I'm missing the reason of their
usage. However, I'm assuming I missed something because they are used
quite heavily.
I don't have experience with autoconf so I may have missed the "right
way" to fix this.
Any comments well apreciated.
radu
On 08/17/2012 04:05 PM, Radu Moisan wrote:
> Signed-off-by: Radu Moisan <radu.moisan at intel.com>
> ---
> .../coreutils-8.17/realpath-works-yes.patch | 13 +++++++++++++
> .../remove-gets.patch | 20 +++++++++++---------
> .../remove-usr-local-lib-from-m4.patch | 0
> .../{coreutils_8.14.bb => coreutils_8.17.bb} | 9 +++++----
> 4 files changed, 29 insertions(+), 13 deletions(-)
> create mode 100644 meta/recipes-core/coreutils/coreutils-8.17/realpath-works-yes.patch
> rename meta/recipes-core/coreutils/{coreutils-8.14 => coreutils-8.17}/remove-gets.patch (47%)
> rename meta/recipes-core/coreutils/{coreutils-8.14 => coreutils-8.17}/remove-usr-local-lib-from-m4.patch (100%)
> rename meta/recipes-core/coreutils/{coreutils_8.14.bb => coreutils_8.17.bb} (91%)
>
> diff --git a/meta/recipes-core/coreutils/coreutils-8.17/realpath-works-yes.patch b/meta/recipes-core/coreutils/coreutils-8.17/realpath-works-yes.patch
> new file mode 100644
> index 0000000..6bbe7ee
> --- /dev/null
> +++ b/meta/recipes-core/coreutils/coreutils-8.17/realpath-works-yes.patch
> @@ -0,0 +1,13 @@
> +Index: coreutils-8.17/m4/canonicalize.m4
> +===================================================================
> +--- coreutils-8.17.orig/m4/canonicalize.m4 2012-05-08 12:05:23.000000000 +0300
> ++++ coreutils-8.17/m4/canonicalize.m4 2012-08-17 14:20:22.000000000 +0300
> +@@ -95,7 +95,7 @@
> + [gl_cv_func_realpath_works=no],
> + [case "$host_os" in
> + # Guess yes on glibc systems.
> +- *-gnu*) gl_cv_func_realpath_works="guessing yes" ;;
> ++ *-gnu*) gl_cv_func_realpath_works="yes" ;;
> + # If we don't know, assume the worst.
> + *) gl_cv_func_realpath_works="guessing no" ;;
> + esac
> diff --git a/meta/recipes-core/coreutils/coreutils-8.14/remove-gets.patch b/meta/recipes-core/coreutils/coreutils-8.17/remove-gets.patch
> similarity index 47%
> rename from meta/recipes-core/coreutils/coreutils-8.14/remove-gets.patch
> rename to meta/recipes-core/coreutils/coreutils-8.17/remove-gets.patch
> index 4f61c92..eaadf7e 100644
> --- a/meta/recipes-core/coreutils/coreutils-8.14/remove-gets.patch
> +++ b/meta/recipes-core/coreutils/coreutils-8.17/remove-gets.patch
> @@ -3,19 +3,21 @@ use gets iff its defined. eglibc 2.16 removed gets
> Signed-off-by: Khem Raj <raj.khem at gmail.com>
> Upstream-Status: Pending
>
> -Index: coreutils-8.14/lib/stdio.in.h
> +Index: coreutils-8.17/lib/stdio.in.h
> ===================================================================
> ---- coreutils-8.14.orig/lib/stdio.in.h 2011-09-24 04:20:48.000000000 -0700
> -+++ coreutils-8.14/lib/stdio.in.h 2012-07-03 10:36:19.886296576 -0700
> -@@ -713,11 +713,13 @@
> - _GL_CXXALIAS_SYS (gets, char *, (char *s));
> - # undef gets
> +--- coreutils-8.17.orig/lib/stdio.in.h
> ++++ coreutils-8.17/lib/stdio.in.h
> +@@ -698,13 +698,14 @@ _GL_WARN_ON_USE (getline, "getline is un
> + "use gnulib module getline for portability");
> # endif
> + #endif
> +-
> +# if defined gets
> - _GL_CXXALIASWARN (gets);
> /* It is very rare that the developer ever has full control of stdin,
> - so any use of gets warrants an unconditional warning. Assume it is
> - always declared, since it is required by C89. */
> + so any use of gets warrants an unconditional warning; besides, C11
> + removed it. */
> + #undef gets
> + #if HAVE_RAW_DECL_GETS
> _GL_WARN_ON_USE (gets, "gets is a security hole - use fgets instead");
> +# endif
> #endif
> diff --git a/meta/recipes-core/coreutils/coreutils-8.14/remove-usr-local-lib-from-m4.patch b/meta/recipes-core/coreutils/coreutils-8.17/remove-usr-local-lib-from-m4.patch
> similarity index 100%
> rename from meta/recipes-core/coreutils/coreutils-8.14/remove-usr-local-lib-from-m4.patch
> rename to meta/recipes-core/coreutils/coreutils-8.17/remove-usr-local-lib-from-m4.patch
> diff --git a/meta/recipes-core/coreutils/coreutils_8.14.bb b/meta/recipes-core/coreutils/coreutils_8.17.bb
> similarity index 91%
> rename from meta/recipes-core/coreutils/coreutils_8.14.bb
> rename to meta/recipes-core/coreutils/coreutils_8.17.bb
> index 9a714a9..9d8170e 100644
> --- a/meta/recipes-core/coreutils/coreutils_8.14.bb
> +++ b/meta/recipes-core/coreutils/coreutils_8.17.bb
> @@ -6,8 +6,8 @@ HOMEPAGE = "http://www.gnu.org/software/coreutils/"
> BUGTRACKER = "http://debbugs.gnu.org/coreutils"
> LICENSE = "GPLv3+"
> LIC_FILES_CHKSUM = "file://COPYING;md5=d32239bcb673463ab874e80d47fae504\
> - file://src/ls.c;startline=5;endline=16;md5=e1a509558876db58fb6667ba140137ad"
> -PR = "r5"
> + file://src/ls.c;startline=5;endline=16;md5=30c84fd2942cad91041e5e2dcd19ced6"
> +PR = "r0"
> DEPENDS = "gmp libcap"
> DEPENDS_virtclass-native = ""
>
> @@ -16,9 +16,10 @@ inherit autotools gettext
> SRC_URI = "${GNU_MIRROR}/coreutils/${BP}.tar.xz \
> file://remove-usr-local-lib-from-m4.patch \
> file://remove-gets.patch \
> + file://realpath-works-yes.patch \
> "
> -SRC_URI[md5sum] = "bcb135ce553493a45aba01b39eb3920a"
> -SRC_URI[sha256sum] = "0d120817c19292edb19e92ae6b8eac9020e03d51e0af9cb116cf82b65d18b02d"
> +SRC_URI[md5sum] = "bbda656ce8ca2c6903948f9faa204ba3"
> +SRC_URI[sha256sum] = "4e075a0d238072a5bd079046e1f024dc5e0d9133d43a39c73d0b86b0d1e2c5e5"
>
> EXTRA_OECONF_virtclass-native = "--without-gmp"
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openembedded.org/pipermail/openembedded-core/attachments/20120817/ea6c156e/attachment-0002.html>
More information about the Openembedded-core
mailing list