On 8/22/12 9:30 AM, Chris Larson wrote:
On Wed, Aug 22, 2012 at 7:26 AM, Khem Raj <[email protected]> wrote:
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..e32f612
--- /dev/null
+++ b/meta/recipes-core/coreutils/coreutils-8.17/realpath-works-yes.patch
@@ -0,0 +1,21 @@
+Signed-off-by: Radu Moisan <[email protected]>
+Upstream status: pending
+
+The new version of coreutils, adds use of canonicalize_file_name() function
defined in canonicalize.h
+The problem: the function is redefined to rpl_canonicalize_file_name by means
of a macro,which gives
+an undefined reference error at compile time. Macro definition depends in the
end on
+gl_cv_func_realpath_works but assumed true only when set to "yes"
+
+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
Wouldn't it be better to provide a cached test result in the site
files for this test, rather than relying on a host_os based guess?
I really don't know the answer to your question. The patch was intended to
provide minimally invasive change to the original file. If you elaborate more
on your proposal, I would gladly take into consideration a future patch to
address this issue.
Add CACHED_CONFIGUREVARS in the recipe search in metadata for existing examples
That's a good route, but only if we know realpath works in 100% of
cases. Which, admittedly, one would certainly hope is the case :)
As far as I know realpath has worked well, for at least the last 6 years (likely
much longer).
--Mark
_______________________________________________
Openembedded-core mailing list
[email protected]
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
