#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@marvell.com --- 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-%%7Bversion%7D.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
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).
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=12f2443a37b9...
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.
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=12f2443a37b9...
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})?