[18/18] erlang: make libatomic_ops optional

The Erlang developers prefer the use of Erlang's native atomics in
Erlang 18. In the previous Erlang release, the native atomics
implementation was not complete and so libatomic_ops was necessary. Now
libatomic_ops is used as a fallback, but based on tests of every
qemu_*_defconfig and several other configs it appears to not be
necessary. In fact, it causes build failures on aarch64. Since it is
conceivable that a platform exists that may still require libatomic_ops,
this change makes the use of the library optional.

Fixes:
http://autobuild.buildroot.net/results/0cd/0cd22eb74fa29e5a85bf897762e16ab3daf33962/

Signed-off-by: Frank Hunleth <fhunleth@troodon-software.com>
---
 package/erlang/Config.in | 10 ++++++++--
 package/erlang/erlang.mk |  2 ++
 2 files changed, 10 insertions(+), 2 deletions(-)

Frank,

On Fri, 22 Jan 2016 20:11:11 -0500, Frank Hunleth wrote:
> The Erlang developers prefer the use of Erlang's native atomics in
> Erlang 18. In the previous Erlang release, the native atomics
> implementation was not complete and so libatomic_ops was necessary. Now
> libatomic_ops is used as a fallback, but based on tests of every
> qemu_*_defconfig and several other configs it appears to not be
> necessary. In fact, it causes build failures on aarch64. Since it is

If using libatomic_ops on aarch64 with erlang causes build failures,
then your BR2_PACKAGE_ERLANG_USE_LIBATOMIC_OPS option should depend
on !BR2_aarch64.

> conceivable that a platform exists that may still require libatomic_ops,
> this change makes the use of the library optional.
> 
> Fixes:
> http://autobuild.buildroot.net/results/0cd/0cd22eb74fa29e5a85bf897762e16ab3daf33962/
> 
> Signed-off-by: Frank Hunleth <fhunleth@troodon-software.com>
> ---
>  package/erlang/Config.in | 10 ++++++++--
>  package/erlang/erlang.mk |  2 ++
>  2 files changed, 10 insertions(+), 2 deletions(-)
> 
> diff --git a/package/erlang/Config.in b/package/erlang/Config.in
> index 0ec01bb..9bd64ac 100644
> --- a/package/erlang/Config.in
> +++ b/package/erlang/Config.in
> @@ -7,8 +7,7 @@ config BR2_PACKAGE_ERLANG
>  	bool "erlang"
>  	depends on BR2_USE_MMU # fork()
>  	depends on !BR2_STATIC_LIBS
> -	depends on BR2_PACKAGE_LIBATOMIC_ARCH_SUPPORTS
> -	select BR2_PACKAGE_LIBATOMIC_OPS
> +	depends on BR2_PACKAGE_LIBATOMIC_ARCH_SUPPORTS # erlang native atomics and libatomic_ops

This shouldn't be here, since you no longer select libatomic_ops.

>  	help
>  	  Erlang is a programming language used to build massively scalable
>  	  soft real-time systems with requirements on high availability.
> @@ -20,6 +19,13 @@ config BR2_PACKAGE_ERLANG
>  
>  if BR2_PACKAGE_ERLANG
>  
> +config BR2_PACKAGE_ERLANG_USE_LIBATOMIC_OPS

We rarely use _USE_ in Config.in options for such cases. Just
BR2_PACKAGE_ERLANG_LIBATOMIC_OPS is enough.

> +	bool "use libatomic_ops"
> +	select BR2_PACKAGE_LIBATOMIC_OPS

This is where you should have the
"depends on BR2_PACKAGE_LIBATOMIC_ARCH_SUPPORTS".

> +	help
> +	  Erlang's native atomic ops implementation is preferred. If this is
> +	  insufficient, enabling this option forces Erlang to use libatomic_ops.

Lines too long I believe.

> +
>  config BR2_PACKAGE_ERLANG_SMP
>  	bool "enable SMP support"
>  	help
> diff --git a/package/erlang/erlang.mk b/package/erlang/erlang.mk
> index dfab30d..a2f75e7 100644
> --- a/package/erlang/erlang.mk
> +++ b/package/erlang/erlang.mk
> @@ -30,8 +30,10 @@ ERLANG_CONF_ENV += erl_xcomp_sysroot=$(STAGING_DIR)
>  
>  ERLANG_CONF_OPTS = --without-javac
>  
> +ifeq ($(BR2_PACKAGE_ERLANG_USE_LIBATOMIC_OPS),y)
>  ERLANG_DEPENDENCIES += libatomic_ops
>  ERLANG_CONF_OPTS += --with-libatomic_ops=$(STAGING_DIR)/usr LIBS=-latomic_ops
> +endif

Can you add a "else" clause to explicitly disable libatomic_ops
support? Otherwise, libatomic_ops may be enabled in the Buildroot
configuration, built before erlang, and detected automatically by
erlang configure script.

Thanks,

Thomas

Thomas,

On Sat, Jan 23, 2016 at 3:25 AM, Thomas Petazzoni
<thomas.petazzoni@free-electrons.com> wrote:
> Frank,
>
> On Fri, 22 Jan 2016 20:11:11 -0500, Frank Hunleth wrote:
>> The Erlang developers prefer the use of Erlang's native atomics in
>> Erlang 18. In the previous Erlang release, the native atomics
>> implementation was not complete and so libatomic_ops was necessary. Now
>> libatomic_ops is used as a fallback, but based on tests of every
>> qemu_*_defconfig and several other configs it appears to not be
>> necessary. In fact, it causes build failures on aarch64. Since it is
>
> If using libatomic_ops on aarch64 with erlang causes build failures,
> then your BR2_PACKAGE_ERLANG_USE_LIBATOMIC_OPS option should depend
> on !BR2_aarch64.
>
>> conceivable that a platform exists that may still require libatomic_ops,
>> this change makes the use of the library optional.
>>
>> Fixes:
>> http://autobuild.buildroot.net/results/0cd/0cd22eb74fa29e5a85bf897762e16ab3daf33962/
>>
>> Signed-off-by: Frank Hunleth <fhunleth@troodon-software.com>
>> ---
>>  package/erlang/Config.in | 10 ++++++++--
>>  package/erlang/erlang.mk |  2 ++
>>  2 files changed, 10 insertions(+), 2 deletions(-)
>>
>> diff --git a/package/erlang/Config.in b/package/erlang/Config.in
>> index 0ec01bb..9bd64ac 100644
>> --- a/package/erlang/Config.in
>> +++ b/package/erlang/Config.in
>> @@ -7,8 +7,7 @@ config BR2_PACKAGE_ERLANG
>>       bool "erlang"
>>       depends on BR2_USE_MMU # fork()
>>       depends on !BR2_STATIC_LIBS
>> -     depends on BR2_PACKAGE_LIBATOMIC_ARCH_SUPPORTS
>> -     select BR2_PACKAGE_LIBATOMIC_OPS
>> +     depends on BR2_PACKAGE_LIBATOMIC_ARCH_SUPPORTS # erlang native atomics and libatomic_ops
>
> This shouldn't be here, since you no longer select libatomic_ops.

I'm having trouble addressing this one. It seems like some "depends
on" clause should be here. The Erlang docs are vague on what all they
support natively, so I was originally thinking that
BR2_PACKAGE_LIBATOMIC_ARCH_SUPPORTS has a good list. Here's the text
from the Erlang docs in case it gives you a good idea on what to do:

"Erlang/OTP itself provides implementations of native atomic memory operations
that can be used when compiling with a `gcc` compatible compiler for 32/64-bit
x86, 32/64-bit SPARC V9, 32-bit PowerPC, or 32-bit Tile. When compiling with
a `gcc` compatible compiler for other architectures, the VM may be able to make
use of native atomic operations using the `__atomic_*` builtins (may be
available when using a `gcc` of at least version 4.7) and/or using the
`__sync_*` builtins (may be available when using a `gcc` of at least version
4.1). If only the `gcc`'s `__sync_*` builtins are available, the performance
will suffer. Such a configuration should only be used as a last resort. When
compiling on Windows using a MicroSoft Visual C++ compiler native atomic
memory operations are provided by Windows APIs.

Native atomic implementation in the order preferred:
1.  The implementation provided by Erlang/OTP.
2.  The API provided by Windows.
3.  The implementation based on the `gcc` `__atomic_*` builtins.
4.  If none of the above are available for your architecture/compiler, you
    are recommended to build and install [libatomic_ops][] before building
    Erlang/OTP. The `libatomic_ops` library provides native atomic memory
    operations for a variety of architectures and compilers. When building
    Erlang/OTP you need to inform the build system of where the
    `libatomic_ops` library is installed using the
    `--with-libatomic_ops=PATH` `configure` switch.
5.  As a last resort, the implementation solely based on the `gcc`
    `__sync_*` builtins. This will however cause lots of expensive and
    unnecessary memory barrier instructions to be issued. That is,
    performance will suffer. The `configure` script will warn at the end
    of its execution if it cannot find any other alternative than this.
"

Or maybe the answer is to delete it and add a !BR2_xyz_platform
whenever the autobuilders catch something. The only platform I know of
that isn't supported is BR2_sparc_v8.

>
>>       help
>>         Erlang is a programming language used to build massively scalable
>>         soft real-time systems with requirements on high availability.
>> @@ -20,6 +19,13 @@ config BR2_PACKAGE_ERLANG
>>
>>  if BR2_PACKAGE_ERLANG
>>
>> +config BR2_PACKAGE_ERLANG_USE_LIBATOMIC_OPS
>
> We rarely use _USE_ in Config.in options for such cases. Just
> BR2_PACKAGE_ERLANG_LIBATOMIC_OPS is enough.
>
>> +     bool "use libatomic_ops"
>> +     select BR2_PACKAGE_LIBATOMIC_OPS
>
> This is where you should have the
> "depends on BR2_PACKAGE_LIBATOMIC_ARCH_SUPPORTS".
>
>> +     help
>> +       Erlang's native atomic ops implementation is preferred. If this is
>> +       insufficient, enabling this option forces Erlang to use libatomic_ops.
>
> Lines too long I believe.
>
>> +
>>  config BR2_PACKAGE_ERLANG_SMP
>>       bool "enable SMP support"
>>       help
>> diff --git a/package/erlang/erlang.mk b/package/erlang/erlang.mk
>> index dfab30d..a2f75e7 100644
>> --- a/package/erlang/erlang.mk
>> +++ b/package/erlang/erlang.mk
>> @@ -30,8 +30,10 @@ ERLANG_CONF_ENV += erl_xcomp_sysroot=$(STAGING_DIR)
>>
>>  ERLANG_CONF_OPTS = --without-javac
>>
>> +ifeq ($(BR2_PACKAGE_ERLANG_USE_LIBATOMIC_OPS),y)
>>  ERLANG_DEPENDENCIES += libatomic_ops
>>  ERLANG_CONF_OPTS += --with-libatomic_ops=$(STAGING_DIR)/usr LIBS=-latomic_ops
>> +endif
>
> Can you add a "else" clause to explicitly disable libatomic_ops
> support? Otherwise, libatomic_ops may be enabled in the Buildroot
> configuration, built before erlang, and detected automatically by
> erlang configure script.

The configure script doesn't provide a --without-libatomic_ops or a
--only-use-native-atomic-ops or anything that I can tell can be used
to disable use of libatomic_ops. Based on my tests, the configure
script does not use libatomic_ops even if present. It's also low down
on their priority list for the atomics implementation to use, so I
think this was intentional.

Also, thanks for the comments on the other patches. I've addressed
those and will submit back after I understand what to do on this one.

Regards,
Frank

Frank,

On Mon, 25 Jan 2016 19:43:05 -0500, Frank Hunleth wrote:

> >> diff --git a/package/erlang/Config.in b/package/erlang/Config.in
> >> index 0ec01bb..9bd64ac 100644
> >> --- a/package/erlang/Config.in
> >> +++ b/package/erlang/Config.in
> >> @@ -7,8 +7,7 @@ config BR2_PACKAGE_ERLANG
> >>       bool "erlang"
> >>       depends on BR2_USE_MMU # fork()
> >>       depends on !BR2_STATIC_LIBS
> >> -     depends on BR2_PACKAGE_LIBATOMIC_ARCH_SUPPORTS
> >> -     select BR2_PACKAGE_LIBATOMIC_OPS
> >> +     depends on BR2_PACKAGE_LIBATOMIC_ARCH_SUPPORTS # erlang native atomics and libatomic_ops
> >
> > This shouldn't be here, since you no longer select libatomic_ops.
> 
> I'm having trouble addressing this one. It seems like some "depends
> on" clause should be here. The Erlang docs are vague on what all they
> support natively, so I was originally thinking that
> BR2_PACKAGE_LIBATOMIC_ARCH_SUPPORTS has a good list.

This one is easy: BR2_PACKAGE_xxx_ARCH_SUPPORTS options are meant to
more easily propagate the architecture dependencies of one package when
you select that package.

Remember that in Buildroot, when a package does:

	select BR2_PACKAGE_<foo>

It *must* replicate the "depends on" that exist in the defintion of
BR2_PACKAGE_<foo>.

For some packages, such dependencies are architecture dependencies,
like:

config BR2_PACKAGE_<foo>
	bool "foo"
	depends on BR2_arm || BR2_armeb || BR2_i386 || BR2_mips || ...

Then in all packages selecting BR2_PACKAGE_<foo>, we would have to
replicate this long "depends on" line. And when this "depends on"
changes, propagate to all reverse dependencies. Not nice.

Hence we rather do:

config BR2_PACKAGE_<foo>_ARCH_SUPPORTS
	bool
	default y if BR2_arm || BR2_armeb || BR2_i386 || BR2_mips || ...

config BR2_PACKAGE_<foo>
	bool "foo"
	depends on BR2_PACKAGE_<foo>_ARCH_SUPPORTS

This way, not only BR2_PACKAGE_<foo> uses
BR2_PACKAGE_<foo>_ARCH_SUPPORTS, but also all reverse dependencies of
the "foo" package.

So, if you are not selecting BR2_PACKAGE_<foo>, there is no reason to
use BR2_PACKAGE_<foo>_ARCH_SUPPORTS. Does that make sense ?

> 
> "Erlang/OTP itself provides implementations of native atomic memory operations
> that can be used when compiling with a `gcc` compatible compiler for 32/64-bit
> x86, 32/64-bit SPARC V9, 32-bit PowerPC, or 32-bit Tile. When compiling with
> a `gcc` compatible compiler for other architectures, the VM may be able to make
> use of native atomic operations using the `__atomic_*` builtins (may be
> available when using a `gcc` of at least version 4.7) and/or using the
> `__sync_*` builtins (may be available when using a `gcc` of at least version
> 4.1). If only the `gcc`'s `__sync_*` builtins are available, the performance
> will suffer. Such a configuration should only be used as a last resort. When
> compiling on Windows using a MicroSoft Visual C++ compiler native atomic
> memory operations are provided by Windows APIs.
> 
> Native atomic implementation in the order preferred:
> 1.  The implementation provided by Erlang/OTP.
> 2.  The API provided by Windows.
> 3.  The implementation based on the `gcc` `__atomic_*` builtins.
> 4.  If none of the above are available for your architecture/compiler, you
>     are recommended to build and install [libatomic_ops][] before building
>     Erlang/OTP. The `libatomic_ops` library provides native atomic memory
>     operations for a variety of architectures and compilers. When building
>     Erlang/OTP you need to inform the build system of where the
>     `libatomic_ops` library is installed using the
>     `--with-libatomic_ops=PATH` `configure` switch.
> 5.  As a last resort, the implementation solely based on the `gcc`
>     `__sync_*` builtins. This will however cause lots of expensive and
>     unnecessary memory barrier instructions to be issued. That is,
>     performance will suffer. The `configure` script will warn at the end
>     of its execution if it cannot find any other alternative than this.
> "

Ah, at least the Erlang documentation is quite verbose and actually
useful. So, let's take this point by point:

 (1) According to their documentation, this is only available on x86
     (not sure 32 bits or 64 bits, let's assume both), SPARC v9,
     PowerPC and Tile (we don't care about Tile).

 (2) We don't care.

 (3) __atomic_*() built-ins are available on *all* architectures,
     provided you link with -latomic.

 (4) libatomic_ops is available on architectures listed in
     BR2_PACKAGE_LIBATOMIC_OPS_ARCH_SUPPORTS

 (5) The availability of __sync_*() operations depend on the
     architectures. See
     http://lists.busybox.net/pipermail/buildroot/2016-January/150744.html
     for the lengthy details. We would actually need to know which
     __sync_*() built-ins Erlang is using. According to
     http://autobuild.buildroot.org/results/209/2090874eee165af3349cf2d597657fc1b4ca1012/build-end.log,
     it needs the 4-byte and 8-byte version.

So, with this in hand, here is how we could encode the architecture
dependency of Erlang:

config BR2_PACKAGE_ERLANG_ARCH_SUPPORTS
	bool
	default y if BR2_i386 || BR2_x86_64 || BR2_powerpc || BR2_sparc_v9 # case (1)
	default y if BR2_TOOLCHAIN_GCC_AT_LEAST_4_7 # case (3)
	default y if BR2_PACKAGE_LIBATOMIC_OPS_ARCH_SUPPORTS # case (4)
	default y if BR2_TOOLCHAIN_HAS_SYNC_4 && BR2_TOOLCHAIN_HAS_SYNC_8 # case (5)

Of course, this should come with a pretty fat comment on top of it that
replicates the good explanation of the Erlang documentation. *And* in
order for case (3) to work, you must make sure that Erlang links with
-latomic.

> >> +ifeq ($(BR2_PACKAGE_ERLANG_USE_LIBATOMIC_OPS),y)
> >>  ERLANG_DEPENDENCIES += libatomic_ops
> >>  ERLANG_CONF_OPTS += --with-libatomic_ops=$(STAGING_DIR)/usr LIBS=-latomic_ops
> >> +endif
> >
> > Can you add a "else" clause to explicitly disable libatomic_ops
> > support? Otherwise, libatomic_ops may be enabled in the Buildroot
> > configuration, built before erlang, and detected automatically by
> > erlang configure script.
> 
> The configure script doesn't provide a --without-libatomic_ops or a
> --only-use-native-atomic-ops or anything that I can tell can be used
> to disable use of libatomic_ops. Based on my tests, the configure
> script does not use libatomic_ops even if present. It's also low down
> on their priority list for the atomics implementation to use, so I
> think this was intentional.

OK, so what you did is good. Maybe just add a comment on top of it.

Also, are you sure LIBS=-latomic_ops is needed ? This seems weird, I
believe Erlang should automatically link against libatomic_ops.

One last thing: do not confuse libatomic and libatomic_ops. They are
completely different things!

Best regards,

Thomas

This patch set pulls in a major update to Erlang. A couple build errors were
introduced by the upgrade which necessitated upgrading several Erlang
packages. It turns out that Erlang's native atomic ops code has been
improved since the last version so that it is now preferred over using
libatomic ops. The final commit that makes the switch away from libatomic_ops
fixes builds on aarch64 without affecting other builds (at least the
qemu_*_defconfigs w/ Erlang and a few other configs.) Erlang autobuilder errors
due to musl are not addressed by this patch set.

Changes v1->v2:
  - Several formatting/SoB fixes
  - Fixed legal-info errors (Thanks Romain)
  - Fixed a missing dependency with erlang-fast_tls (Thanks Romain)
  - Reworked final patch for choosing atomic ops implementation based
    on many helpful comments from Thomas.

Frank Hunleth (18):
  erlang: bump to version 18.2.1
  pkg-rebar.mk: pass C++ compiler path and options
  erlang-goldrush: bump to version 0.1.8
  erlang-lager: bump to version 2.2.0
  erlang-rebar: bump to version 2.6.1
  erlang-fast_tls: new package
  erlang-p1-cache-tab: bump to version 1.0.1
  erlang-p1-iconv: bump to version 0.9.0
  erlang-p1-stringprep: bump to version 1.0.0
  erlang-p1_stun: bump to version 0.9.0
  erlang-p1-sip: bump to version 1.0.0
  erlang-p1-tls: bump to version 1.0.0
  erlang-p1-utils: bump to version 1.0.3
  erlang-p1-xml: bump to version 1.1.1
  erlang-p1-yaml: bump to version 1.0.0
  erlang-p1-zlib: bump to version 1.0.0
  ejabberd: bump to version 16.01
  erlang: support choosing atomic ops

 package/Config.in                                  |  3 +-
 ...001-remove-dependencies-from-rebar-config.patch | 83 ++++++++++++++++++++++
 package/ejabberd/0001-remove-deps.patch            | 22 ------
 package/ejabberd/0002-disable-rebar-deps.patch     | 76 --------------------
 .../0002-remove-make-targets-for-deps.patch        | 74 +++++++++++++++++++
 package/ejabberd/0003-disable-test.patch           | 27 -------
 .../0003-remove-checking-erlang-version.patch      | 30 ++++++++
 package/ejabberd/0004-correct-include.patch        | 56 +++++++++++++++
 package/ejabberd/0004-disable-version-check.patch  | 20 ------
 .../0005-disable-ERLANG_DEPRECATED_CHECK.patch     | 27 +++++++
 package/ejabberd/0005-fix-includes.patch           | 45 ------------
 ...006-disable-erlang-deprecated-types-check.patch | 20 ------
 ...ns.patch => 0006-fix-install-permissions.patch} | 41 +++++------
 ...jabberdctl.patch => 0007-fix-ejabberdctl.patch} | 21 ++++--
 package/ejabberd/Config.in                         |  5 +-
 package/ejabberd/ejabberd.hash                     |  6 +-
 package/ejabberd/ejabberd.mk                       |  2 +-
 package/erlang-fast_tls/Config.in                  |  8 +++
 package/erlang-fast_tls/erlang-fast_tls.mk         | 14 ++++
 package/erlang-goldrush/erlang-goldrush.mk         |  2 +-
 package/erlang-lager/erlang-lager.mk               |  2 +-
 package/erlang-p1-cache-tab/erlang-p1-cache-tab.mk |  4 +-
 package/erlang-p1-iconv/erlang-p1-iconv.mk         |  2 +-
 package/erlang-p1-sip/erlang-p1-sip.mk             |  4 +-
 package/erlang-p1-stringprep/Config.in             |  4 ++
 .../erlang-p1-stringprep/erlang-p1-stringprep.mk   |  2 +-
 package/erlang-p1-tls/erlang-p1-tls.mk             |  2 +-
 package/erlang-p1-utils/erlang-p1-utils.mk         |  4 +-
 package/erlang-p1-xml/erlang-p1-xml.mk             |  4 +-
 package/erlang-p1-yaml/erlang-p1-yaml.mk           |  2 +-
 package/erlang-p1-zlib/erlang-p1-zlib.mk           |  2 +-
 .../{erlang-p1-stun => erlang-p1_stun}/Config.in   |  4 +-
 .../erlang-p1_stun.mk}                             |  6 +-
 package/erlang-rebar/erlang-rebar.mk               |  2 +-
 ...04-erts-fix-incorrect-use-of-ac-egrep-cpp.patch | 79 --------------------
 package/erlang/Config.in                           | 55 ++++++++++++--
 package/erlang/erlang.hash                         |  5 +-
 package/erlang/erlang.mk                           | 16 +++--
 package/pkg-rebar.mk                               |  2 +
 39 files changed, 426 insertions(+), 357 deletions(-)
 create mode 100644 package/ejabberd/0001-remove-dependencies-from-rebar-config.patch
 delete mode 100644 package/ejabberd/0001-remove-deps.patch
 delete mode 100644 package/ejabberd/0002-disable-rebar-deps.patch
 create mode 100644 package/ejabberd/0002-remove-make-targets-for-deps.patch
 delete mode 100644 package/ejabberd/0003-disable-test.patch
 create mode 100644 package/ejabberd/0003-remove-checking-erlang-version.patch
 create mode 100644 package/ejabberd/0004-correct-include.patch
 delete mode 100644 package/ejabberd/0004-disable-version-check.patch
 create mode 100644 package/ejabberd/0005-disable-ERLANG_DEPRECATED_CHECK.patch
 delete mode 100644 package/ejabberd/0005-fix-includes.patch
 delete mode 100644 package/ejabberd/0006-disable-erlang-deprecated-types-check.patch
 rename package/ejabberd/{0007-fix-install-permissions.patch => 0006-fix-install-permissions.patch} (73%)
 rename package/ejabberd/{0008-fix-ejabberdctl.patch => 0007-fix-ejabberdctl.patch} (56%)
 create mode 100644 package/erlang-fast_tls/Config.in
 create mode 100644 package/erlang-fast_tls/erlang-fast_tls.mk
 rename package/{erlang-p1-stun => erlang-p1_stun}/Config.in (70%)
 rename package/{erlang-p1-stun/erlang-p1-stun.mk => erlang-p1_stun/erlang-p1_stun.mk} (77%)
 delete mode 100644 package/erlang/0004-erts-fix-incorrect-use-of-ac-egrep-cpp.patch