Message ID | 1360749821-19238-1-git-send-email-alexander.lukichev@gmail.com |
---|---|
State | Superseded |
Headers | show |
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
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
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
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
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
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
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
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))