[RFC] /site question

[RFC] /site question

[Denis 'GNUtoo' Carikli]

hi,
I only know what site is for,but:
*I'm not confident with it
*I bet it needs review before touching it
*I wouldn't know in which file I should add the changes
  Maybe common-glibc?

The issue I faced was that btoc.m4 wcrtomb.m4 had no
  defined behaviour in the case of cross-compilation in
  AC_TRY_RUN in fastjar 0.98

The attached patch is a first attempt to fix this issue 
  and is only here for better explanation of the issue
  (it doesn't even patch the site files)

Denis.

[PATCH] DO_NOT_COMMIT_YET: fastjar: handle cross-compilation

[Denis 'GNUtoo' Carikli]

  btoc(m4 macro)'s AC_TRY_RUN didn't handle the cross-compilation case.
  thanks ? for telling me that the third argument
  was for cross-compilation.

Signed-off-by: Denis 'GNUtoo' Carikli <GNUtoo@no-log.org>
---
 recipes/fastjar/fastjar-0.98/btowc_eof.patch |   13 +++++++++++++
 recipes/fastjar/fastjar-0.98/wcrtomb.patch   |   13 +++++++++++++
 recipes/fastjar/fastjar_0.98.bb              |    2 ++
 3 files changed, 28 insertions(+), 0 deletions(-)
 create mode 100644 recipes/fastjar/fastjar-0.98/btowc_eof.patch
 create mode 100644 recipes/fastjar/fastjar-0.98/wcrtomb.patch

diff --git a/recipes/fastjar/fastjar-0.98/btowc_eof.patch b/recipes/fastjar/fastjar-0.98/btowc_eof.patch
new file mode 100644
index 0000000..b76e491
--- /dev/null
+++ b/recipes/fastjar/fastjar-0.98/btowc_eof.patch
@@ -0,0 +1,13 @@
+Index: fastjar-0.98/m4/btowc.m4
+===================================================================
+--- fastjar-0.98.orig/m4/btowc.m4
++++ fastjar-0.98/m4/btowc.m4
+@@ -47,7 +47,7 @@ int main ()
+ }],
+             [gl_cv_func_btowc_eof=yes],
+             [gl_cv_func_btowc_eof=no],
+-            [])
++            [gl_cv_func_btowc_eof=yes])
+         fi
+       ])
+     case "$gl_cv_func_btowc_eof" in
diff --git a/recipes/fastjar/fastjar-0.98/wcrtomb.patch b/recipes/fastjar/fastjar-0.98/wcrtomb.patch
new file mode 100644
index 0000000..9d3133d
--- /dev/null
+++ b/recipes/fastjar/fastjar-0.98/wcrtomb.patch
@@ -0,0 +1,13 @@
+Index: fastjar-0.98/m4/wcrtomb.m4
+===================================================================
+--- fastjar-0.98.orig/m4/wcrtomb.m4
++++ fastjar-0.98/m4/wcrtomb.m4
+@@ -67,7 +67,7 @@ int main ()
+ }],
+             [gl_cv_func_wcrtomb_retval=yes],
+             [gl_cv_func_wcrtomb_retval=no],
+-            [])
++            [gl_cv_func_wcrtomb_retval=yes])
+         fi
+       ])
+     case "$gl_cv_func_wcrtomb_retval" in
diff --git a/recipes/fastjar/fastjar_0.98.bb b/recipes/fastjar/fastjar_0.98.bb
index 35392f2..76b28e2 100644
--- a/recipes/fastjar/fastjar_0.98.bb
+++ b/recipes/fastjar/fastjar_0.98.bb
@@ -1 +1,3 @@
 require fastjar.inc
+SRC_URI += " file://btowc_eof.patch;patch=1 \
+             file://wcrtomb.patch;patch=1"
-- 
1.6.4.4

Re: [PATCH] DO_NOT_COMMIT_YET: fastjar: handle cross-compilation

[Chris Larson]

On Sun, Mar 28, 2010 at 9:44 AM, Denis 'GNUtoo' Carikli
<GNUtoo@no-log.org>wrote:

>
>  btoc(m4 macro)'s AC_TRY_RUN didn't handle the cross-compilation case.
>  thanks ? for telling me that the third argument
>  was for cross-compilation.



Using the third argument for this sort of thing is not ideal.. in fact, I've
experimented with patching the autoconf macros to disable it.  The only time
you should consider using it is when the test is only for a sanity check,
and its result does not affect behavior.  When the result does affect
behavior and clearly isn't a sanity check, setting an assumed default
knowing nothing about the target environment is not the way to go.  You
should use the CONFIG_SITE / site files to feed in the test result as
appropriate for the platform, coupled with wrapping the AC_TRY_RUN call in
AC_CACHE_CHECK, to ensure it obeys it.
-- 
Christopher Larson
clarson at kergoth dot com
Founder - BitBake, OpenEmbedded, OpenZaurus
Maintainer - Tslib
Senior Software Engineer, Mentor Graphics

Re: [PATCH] DO_NOT_COMMIT_YET: fastjar: handle cross-compilation

[GNUtoo]

> Using the third argument for this sort of thing is not ideal.. in fact, I've
> experimented with patching the autoconf macros to disable it.  
I know,I sent the patch only for explaining better the issue,
I didn't plan at any moment to use that patch.
I just wanted an howto,in order to use the site files.

> The only time
> you should consider using it is when the test is only for a sanity check,
> and its result does not affect behavior.  When the result does affect
> behavior and clearly isn't a sanity check, setting an assumed default
> knowing nothing about the target environment is not the way to go.
I tested the default running the tests,that is to say:
devshell,copy-paste the test,compile them,run them on target.
>   You
> should use the CONFIG_SITE / site files to feed in the test result as
> appropriate for the platform, 
That's exactly what I wanted to do,but unfortunately as I said in the
first mail:
*I'm not confident with it
*I bet it needs review before touching it
*I wouldn't know in which file I should add the changes(Maybe
common-glibc?)
> coupled with wrapping the AC_TRY_RUN call in
> AC_CACHE_CHECK, to ensure it obeys it.
I didn't know that I needed to do that,
thanks a lot,
I'll try to find out how to do it.

Denis.