[Buildroot] [PATCH v3 1/1] openpgm: new package

[Buildroot] [PATCH v3 1/1] openpgm: new package

[Alexander Lukichev]

From: Alexander Lukichev <alexander.lukichev@espotel.com>

OpenPGM is an open source implementation of the Pragmatic General
Multicast (PGM) specification in RFC 3208 available at www.ietf.org.
It is required for PGM/EPGM support in ZeroMQ library.

Signed-off-by: Alexander Lukichev <alexander.lukichev@gmail.com>
---
v3: improved according to community suggestions:
- added Signed-off-by and the reason to the cross-compilation patch;
- specified toolchain requirements in Config.in.

The package can be built without WCHAR but this is supported
only by its SCons and CMake build systems (for development). Autotools
based build system (for releases) does not support this. IPV6 and
thread support requirements are mandatory.

v2: improved according to community suggestions:
- legal information supplied;
- OPENPGM_SUBDIR is used instead of a post extract hook;
- more recent release of the package is used;
- cross-compilation fix uses cached values instead of hard-coded ones.

The last thing has been implemented as recommended in Autoconf manual
(http://www.gnu.org/savannah-checkouts/gnu/autoconf/manual/autoconf-2.69/html_node/Runtime.html#Runtime)
for cross-compilation-friendly runtime tests. Direct caching of
pgm_unaligned_pointers variable produced a warning during autoreconfigure
that said that only variables containing _cv_ were cached, and
ac_cv_lbl_unaligned_fail was already used in Buildroot, so I based the
test on that one and set pgm_unaligned_pointers later from its result.
---
 package/Config.in                           |  1 +
 package/openpgm/Config.in                   | 16 ++++++++++++
 package/openpgm/openpgm-cross-compile.patch | 38 +++++++++++++++++++++++++++++
 package/openpgm/openpgm.mk                  | 18 ++++++++++++++
 4 files changed, 73 insertions(+)
 create mode 100644 package/openpgm/Config.in
 create mode 100644 package/openpgm/openpgm-cross-compile.patch
 create mode 100644 package/openpgm/openpgm.mk

diff --git a/package/Config.in b/package/Config.in
index 2fad94d..bfaf944 100644
--- a/package/Config.in
+++ b/package/Config.in
@@ -524,6 +524,7 @@ source "package/libtorrent/Config.in"
 source "package/libupnp/Config.in"
 source "package/libvncserver/Config.in"
 source "package/nss-mdns/Config.in"
+source "package/openpgm/Config.in"
 source "package/ortp/Config.in"
 source "package/slirp/Config.in"
 source "package/usbredir/Config.in"
diff --git a/package/openpgm/Config.in b/package/openpgm/Config.in
new file mode 100644
index 0000000..1b385a3
--- /dev/null
+++ b/package/openpgm/Config.in
@@ -0,0 +1,16 @@
+config BR2_PACKAGE_OPENPGM
+	bool "openpgm"
+	depends on BR2_TOOLCHAIN_HAS_THREADS
+	depends on BR2_INET_IPV6
+	depends on BR2_USE_WCHAR
+	help
+	  OpenPGM is an open source implementation of the Pragmatic General
+	  Multicast (PGM) specification in RFC 3208 available at www.ietf.org.
+	  PGM is a reliable and scalable multicast protocol that enables
+	  receivers to detect loss, request retransmission of lost data, or
+	  notify an application of unrecoverable loss.
+
+	  http://code.google.com/p/openpgm/
+
+comment "openpgm needs a toolchain with WCHAR, threads and IPv6 support"
+	depends on !(BR2_TOOLCHAIN_HAS_THREADS && BR2_INET_IPV6 && BR2_USE_WCHAR)
diff --git a/package/openpgm/openpgm-cross-compile.patch b/package/openpgm/openpgm-cross-compile.patch
new file mode 100644
index 0000000..07a2449
--- /dev/null
+++ b/package/openpgm/openpgm-cross-compile.patch
@@ -0,0 +1,38 @@
+configure.ac: cross-compilation fix
+
+This patch enables to configure the package when cross-compiling in a way
+recommended by Autoconf manual (see manual for version 2.69, Section 6.6
+Checking Runtime Behavior).
+
+Signed-off-by: Alexander Lukichev <alexander.lukichev@gmail.com>
+
+--- a/openpgm/pgm/configure.ac	2011-09-27 20:59:08.000000000 +0300
++++ b/openpgm/pgm/configure.ac	2013-02-12 10:33:53.000000000 +0200
+@@ -272,14 +272,19 @@ uint32_t add32_with_carry (uint32_t a, u
+ 	;;
+ esac
+ # ticket spinlock friendly: unaligned pointers & atomic ops (excl. Sun Pro)
+-AC_MSG_CHECKING([for unaligned pointers])
+-AC_RUN_IFELSE(
+-	[AC_LANG_PROGRAM([[char* nezumi = "mouse";]],
+-		[[short x = *(short*)(nezumi + 2)]])],
+-	[AC_MSG_RESULT([yes])
+-		pgm_unaligned_pointers=yes],
+-	[AC_MSG_RESULT([no])
+-		pgm_unaligned_pointers=no])
++AC_CACHE_CHECK([if unaligned access fails], [ac_cv_lbl_unaligned_fail],
++	[AC_RUN_IFELSE(
++		[AC_LANG_PROGRAM([[char* nezumi = "mouse";]],
++			[[short x = *(short*)(nezumi + 2)]])],
++		[ac_cv_lbl_unaligned_fail=no],
++		[ac_cv_lbl_unaligned_fail=yes],
++		[ac_cv_lbl_unaligned_fail=yes])
++	])
++if test "$ac_cv_lbl_unaligned_fail" = yes; then
++	pgm_unaligned_pointers=no
++else
++	pgm_unaligned_pointers=yes
++fi
+ AC_MSG_CHECKING([for intrinsic atomic ops])
+ # AC_PREPROC_IFELSE not always portable
+ AC_COMPILE_IFELSE(
diff --git a/package/openpgm/openpgm.mk b/package/openpgm/openpgm.mk
new file mode 100644
index 0000000..34c5965
--- /dev/null
+++ b/package/openpgm/openpgm.mk
@@ -0,0 +1,18 @@
+#############################################################
+#
+# openpgm
+#
+#############################################################
+
+OPENPGM_VERSION = 5.2.121~dfsg
+OPENPGM_SOURCE = libpgm-$(OPENPGM_VERSION).tar.gz
+OPENPGM_SITE = http://openpgm.googlecode.com/files/
+OPENPGM_LICENSE = LGPLv2.1+
+OPENPGM_LICENSE_FILES = openpgm/pgm/LICENSE
+OPENPGM_INSTALL_STAGING = YES
+OPENPGM_AUTORECONF = YES
+OPENPGM_SUBDIR = openpgm/pgm/
+OPENPGM_CONF_ENV = ac_cv_file__proc_cpuinfo=yes ac_cv_file__dev_rtc=no \
+                   ac_cv_file__dev_hpet=no
+
+$(eval $(autotools-package))
-- 
1.8.0.1

[Buildroot] [PATCH v3 1/1] openpgm: new package

[Arnout Vandecappelle]

On 13/02/13 11:03, Alexander Lukichev wrote:
> OpenPGM is an open source implementation of the Pragmatic General
> Multicast (PGM) specification in RFC 3208 available atwww.ietf.org.
> It is required for PGM/EPGM support in ZeroMQ library.
>
> Signed-off-by: Alexander Lukichev<alexander.lukichev@gmail.com>
> ---
> v3: improved according to community suggestions:
> - added Signed-off-by and the reason to the cross-compilation patch;
> - specified toolchain requirements in Config.in.
>
> The package can be built without WCHAR but this is supported
> only by its SCons and CMake build systems (for development). Autotools
> based build system (for releases) does not support this. IPV6 and
> thread support requirements are mandatory.

  In that case, why not just use cmake instead of autotools?

  Regards,
  Arnout

-- 
Arnout Vandecappelle                          arnout at mind be
Senior Embedded Software Architect            +32-16-286500
Essensium/Mind                                http://www.mind.be
G.Geenslaan 9, 3001 Leuven, Belgium           BE 872 984 063 RPR Leuven
LinkedIn profile: http://www.linkedin.com/in/arnoutvandecappelle
GPG fingerprint:  7CB5 E4CC 6C2E EFD4 6E3D A754 F963 ECAB 2450 2F1F

[Buildroot] [PATCH v3 1/1] openpgm: new package

[Alexander Lukichev]

Hi, Arnout, All!

On 02/14/2013 12:12 AM, Arnout Vandecappelle wrote:
>> The package can be built without WCHAR but this is supported
>> only by its SCons and CMake build systems (for development). Autotools
>> based build system (for releases) does not support this. IPV6 and
>> thread support requirements are mandatory.
>  In that case, why not just use cmake instead of autotools?

To quote the INSTALL for the package:
"Note this package includes three build systems each with different targets:

 * SCons is used for development, there is minimal auto-configuration, one
   SConstruct script per target compiler and platform.

 * Autoconf is used for Unix-only library release.

 * CMake is used for Windows-only library release and installer packaging.
"

--
Best regards,
  Alexander Lukichev

[Buildroot] [PATCH v3 1/1] openpgm: new package

[Alexander Lukichev]

Hi, All!

On 02/14/2013 07:38 AM, Alexander Lukichev wrote:
>>> The package can be built without WCHAR but this is supported
>>> only by its SCons and CMake build systems (for development). Autotools
>>> based build system (for releases) does not support this. IPV6 and
>>> thread support requirements are mandatory.
>>  In that case, why not just use cmake instead of autotools?
> To quote the INSTALL for the package:
> "* Autoconf is used for Unix-only library release.
>  * CMake is used for Windows-only library release and installer packaging."

  Could I please ask about the status of this patch? Does it need some improvements or is it completely useless? Thanks.

--
Best regards,
  Alexander Lukichev

[Buildroot] [PATCH v3 1/1] openpgm: new package

[Alexander Lukichev]

Hello,

On 02/13/2013 12:03 PM, Alexander Lukichev wrote:
> From: Alexander Lukichev <alexander.lukichev@espotel.com>
> 
> OpenPGM is an open source implementation of the Pragmatic General
> Multicast (PGM) specification in RFC 3208 available at www.ietf.org.
> It is required for PGM/EPGM support in ZeroMQ library.
> 
> Signed-off-by: Alexander Lukichev <alexander.lukichev@gmail.com>

  I won't do it again but would like to inquire once more about the
patch. Is it lost/ignored/useless? Maybe it could be improved?

  The reason for the patch was to add support for PGM/EPGM protocol
in zeromq 2.2.0 library, which is already present in Buildroot.

The source of zeromq comes with an archive of openpgm, and during a
build of zeromq this pre-packaged version of openpgm can also be
built, but this phase of the build process is not very cross-compiler-
friendly, i.e.:
  - the archive is unpacked, configure and make are executed from the
    configure script of zeromq;
  - some openpgm configure.ac tests do not account for cross builds,
    you have to set up specific environment and patch configure.ac
    to cross build.

So in order to cross build openpgm, pre-packaged in zeromq sources,
zeromq's configure.in has to be patched and configure script
regenerated before starting zeromq build. Since you don't have to do
it if PGM/EPGM support is not needed, this looks somewhat weird:
adding PGM/EPGM support needs patching configure.in and regenerating
configure to patch and reconfigure openpgm's autoconf scripts. All
because openpgm autoconf tests are not cross-build-friendly which is
openpgm's problem, not zeromq's.

  On the other hand, support for PGM/EPGM in zeromq can be added
when it is built also with --with-system-pgm configure option, which
allows for entirely independent build and installation of openpgm.
This approach allows to solve openpgm's cross build issues without
tweaking zeromq. It seemed a cleaner approach, which was taken in
this patch.

  After this patch is applied, in order to add support for PGM/EPGM
in zeromq, you have to pass --with-system-pgm option to configure,
and add a dependency on openpgm package in packages/zeromq/zeromq.mk,
the patch for which I planned to send if this patch was accepted.

  I have build-tested the patch in several architectures and toolchain
combinations, and run-tested the built library in x86 (eglibc,
uClibc 0.9.33) and ARM (uClibc 0.9.33).

  Thank you for any feedback and thoughts you might have on this.

--
Best regards,
  Alexander Lukichev

[Buildroot] [PATCH v3 1/1] openpgm: new package

[Thomas Petazzoni]

Dear Alexander Lukichev,

On Fri, 01 Mar 2013 08:46:36 +0200, Alexander Lukichev wrote:

>   I won't do it again but would like to inquire once more about the
> patch. Is it lost/ignored/useless? Maybe it could be improved?

No, it has not been lost. Patches are never lost, because they are
automatically recorded in our Patchwork system, see
http://patchwork.ozlabs.org/project/buildroot/list/. Your patch is
still listed in http://patchwork.ozlabs.org/patch/220105/.

February was the month of the -rc releases, so Peter has been mainly
focused on fixing things and merging fixes. He did merge a few things
in the "next" branch, but not much. Now that 2013.02 has been released,
the "master" branch has reopened to new developments and new packages,
and I expect that Peter will therefore restart merging things more
aggresively.

>   The reason for the patch was to add support for PGM/EPGM protocol
> in zeromq 2.2.0 library, which is already present in Buildroot.

Could you send the patch that makes the ZeroMQ change to use the
openpgm package?

>   On the other hand, support for PGM/EPGM in zeromq can be added
> when it is built also with --with-system-pgm configure option, which
> allows for entirely independent build and installation of openpgm.
> This approach allows to solve openpgm's cross build issues without
> tweaking zeromq. It seemed a cleaner approach, which was taken in
> this patch.

I completely agree with your approach.

>   After this patch is applied, in order to add support for PGM/EPGM
> in zeromq, you have to pass --with-system-pgm option to configure,
> and add a dependency on openpgm package in packages/zeromq/zeromq.mk,
> the patch for which I planned to send if this patch was accepted.

Could you send both patches in a small series of two patches? You don't
need to wait for the first patch to be merged to show the second patch.
Most people do series of patches when they need multiple related things
to be merged (see for example the 30 patches series I sent regarding
Qt5).

>   I have build-tested the patch in several architectures and toolchain
> combinations, and run-tested the built library in x86 (eglibc,
> uClibc 0.9.33) and ARM (uClibc 0.9.33).

Great, thanks for all your testing.

For sure your patch will get merged.

Best regards,

Thomas
-- 
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com

[Buildroot] [PATCH v3 1/1] openpgm: new package

[Alexander Lukichev]

Hi, Thomas!

  Thanks for the heads-up! I was a bit lost. :)

On 03/01/2013 11:24 AM, Thomas Petazzoni wrote:
>>   The reason for the patch was to add support for PGM/EPGM protocol
>> in zeromq 2.2.0 library, which is already present in Buildroot.
> Could you send the patch that makes the ZeroMQ change to use the
> openpgm package?

  Which one you mean: the one that uses a pre-packaged openpgm or the
one that uses a separate openpgm?

> Could you send both patches in a small series of two patches? You don't

  I'll do that. The series will have "[PATCH v4 x/2] openpgm: new package"
subject. Is this OK (like, the v3 patch has been appended with an
additional patch but otherwise it's about the same subject)?

--
Best regards,
  Alexander Lukichev

[Buildroot] [PATCH v3 1/1] openpgm: new package

[Thomas Petazzoni]

Dear Alexander Lukichev,

On Fri, 01 Mar 2013 11:41:52 +0200, Alexander Lukichev wrote:

> On 03/01/2013 11:24 AM, Thomas Petazzoni wrote:
> >>   The reason for the patch was to add support for PGM/EPGM protocol
> >> in zeromq 2.2.0 library, which is already present in Buildroot.
> > Could you send the patch that makes the ZeroMQ change to use the
> > openpgm package?
> 
>   Which one you mean: the one that uses a pre-packaged openpgm or the
> one that uses a separate openpgm?

The one that uses a separate openpgm, since you've submitted it as a
package.

> > Could you send both patches in a small series of two patches? You don't
> 
>   I'll do that. The series will have "[PATCH v4 x/2] openpgm: new package"
> subject. Is this OK (like, the v3 patch has been appended with an
> additional patch but otherwise it's about the same subject)?

That's fine.

[PATCH v4 1/2] openpgm: new package
[PATCH v4 2/2] zeromq: add support to build PGM support

Best regards,

Thomas
-- 
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com