[PATCH] libidn: Fix problem with #include_next

[Kedar Sovani]

#include_next is not understood by the compiler, and hence it gives up. 

(I don't understand why this is not seen in x86 builds, comments?)


(http://www.gnu.org/software/gnulib/manual/html_node/stdint_002eh.html)

Signed-off-by: Kedar Sovani <kedars(a)marvell.com&gt;
---
 libidn-0.6.14-include-next.patch |   12 ++++++++++++
 libidn.spec                      |    6 +++++-
 2 files changed, 17 insertions(+), 1 deletions(-)
 create mode 100644 libidn-0.6.14-include-next.patch

diff --git a/libidn-0.6.14-include-next.patch b/libidn-0.6.14-include-next.patch
new file mode 100644
index 0000000..d28ea9d
--- /dev/null
+++ b/libidn-0.6.14-include-next.patch
@@ -0,0 +1,12 @@
+diff -urp libidn-0.6.14.orig/lib/Makefile.am libidn-0.6.14/lib/Makefile.am
+--- libidn-0.6.14.orig/lib/Makefile.am	2007-05-31 06:31:00.000000000 -0400
++++ libidn-0.6.14/lib/Makefile.am	2008-12-16 00:25:12.000000000 -0500
+@@ -37,7 +37,7 @@ nodist_include_HEADERS = $(idn_int)
+ 
+ idn-int.h:
+ 	if test -n "$(STDINT_H)"; then \
+-		cp gl/stdint.h idn-int.h; \
++		sed -e s/include_next/include/ gl/stdint.h > idn-int.h; \
+ 	else \
+ 		echo '#include <stdint.h>' > idn-int.h; \
+ 	fi
diff --git a/libidn.spec b/libidn.spec
index b9b266e..76d2b35 100644
--- a/libidn.spec
+++ b/libidn.spec
@@ -1,11 +1,12 @@
 Summary: Internationalized Domain Name support library
 Name: libidn
 Version: 0.6.14
-Release: 8
+Release: 8.fa1
 URL: http://www.gnu.org/software/libidn/
 License: LGPLv2+
 Source0: http://josefsson.org/libidn/releases/libidn-%{version}.tar.gz
 Patch0: libidn-0.6.14-aconf262.patch
+Patch1: libidn-0.6.14-include-next.patch
 Group: System Environment/Libraries
 BuildRoot: %{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n)
 BuildRequires: pkgconfig, gettext, libtool, autoconf
@@ -33,6 +34,9 @@ developing programs which use the GNU libidn library.
 %prep
 %setup -q
 %patch0 -p1 -b .aconf262
+%ifarch %{arm}
+%patch1 -p1 -b .include-next-fix
+%endif
 
 # Name directory sections consistently in the info file, #209491
 sed -i '/^INFO-DIR-SECTION/{s/GNU Libraries/Libraries/;s/GNU
utilities/Utilities/;}' doc/libidn.info
-- 
1.5.3.3

[Lennert Buytenhek]

On Mon, Dec 29, 2008 at 03:43:52PM +0530, Kedar Sovani wrote:

>  #include_next is not understood by the compiler, and hence it gives
> up. 
>  
>  (I don't understand why this is not seen in x86 builds, comments?) 
Probably because the binary package in the archive was built with
some older gcc version, or something like that.  Try rebuilding the
package on x86 on a fully updated root fs and see if it still happens?


>   %prep
>   %setup -q
>   %patch0 -p1 -b .aconf262
>  +%ifarch %{arm}
>  +%patch1 -p1 -b .include-next-fix
>  +%endif 
Don't make patches dependent on the build environment (I think there
is a rule forbidding doing what you're doing here).

[Kedar Sovani]

On Mon, 2008-12-29 at 11:25 +0100, Lennert Buytenhek wrote:
>  On Mon, Dec 29, 2008 at 03:43:52PM +0530, Kedar Sovani wrote:
>  
>  > #include_next is not understood by the compiler, and hence it gives up. 
>  > 
>  > (I don't understand why this is not seen in x86 builds, comments?)
>  
>  Probably because the binary package in the archive was built with
>  some older gcc version, or something like that.  Try rebuilding the
>  package on x86 on a fully updated root fs and see if it still happens?
>  
>  
>  >  %prep
>  >  %setup -q
>  >  %patch0 -p1 -b .aconf262
>  > +%ifarch %{arm}
>  > +%patch1 -p1 -b .include-next-fix
>  > +%endif
>  
>  Don't make patches dependent on the build environment (I think there
>  is a rule forbidding doing what you're doing here). 
The patch has appeared upstream at the libidn project (31 Aug 2007):

http://git.savannah.gnu.org/gitweb/?p=libidn.git;a=commitdiff;h=12f2443a3...

It seems the Fedora libidn has been using version 0.6.14, while upstream
has moved to version 1.0, about 16 months ago.


Kedar.

[Lennert Buytenhek]

On Mon, Dec 29, 2008 at 04:18:55PM +0530, Kedar Sovani wrote:

>  > > #include_next is not understood by the compiler, and hence
> it gives up. 
>  > > 
>  > > (I don't understand why this is not seen in x86 builds, comments?)
>  > 
>  > Probably because the binary package in the archive was built with
>  > some older gcc version, or something like that.  Try rebuilding the
>  > package on x86 on a fully updated root fs and see if it still happens?
>  > 
>  > 
>  > >  %prep
>  > >  %setup -q
>  > >  %patch0 -p1 -b .aconf262
>  > > +%ifarch %{arm}
>  > > +%patch1 -p1 -b .include-next-fix
>  > > +%endif
>  > 
>  > Don't make patches dependent on the build environment (I think there
>  > is a rule forbidding doing what you're doing here).
>  
>  The patch has appeared upstream at the libidn project (31 Aug 2007):
>  
>
> http://git.savannah.gnu.org/gitweb/?p=libidn.git;a=commitdiff;h=12f2443a3...
>  
>  It seems the Fedora libidn has been using version 0.6.14, while upstream
>  has moved to version 1.0, about 16 months ago. 
What I mean is, just include it unconditionally (i.e. not dependent
on %{arm})?