Fedora build -- unique pointers

[DanGrayson]

on Fedora with gcc version 10.1.1 on the release-1.15 branch:

make: Entering directory '/home/dan/src/M2/M2/BUILD/dan/builds.tmp/fedora-release-1.15/Macaulay2/e'
CXX f4/res-moninfo-dense.cpp
In file included from /usr/include/c++/10/memory:83,
                 from /home/dan/src/M2/M2/Macaulay2/e/f4/res-moninfo-dense.hpp:13,
                 from /home/dan/src/M2/M2/Macaulay2/e/f4/res-moninfo-dense.cpp:3:
/usr/include/c++/10/bits/unique_ptr.h: In instantiation of ‘constexpr std::unique_ptr<_Tp [], _Dp>::unique_ptr() [with _Del = std::default_delete<int []>; <template-parameter-2-2> = void; _Tp = int; _Dp = std::default_delete<int []>]’:
/home/dan/src/M2/M2/Macaulay2/e/f4/res-moninfo-dense.cpp:10:65:   required from here
/usr/include/c++/10/bits/unique_ptr.h:530:9: error: no matching function for call to ‘std::__uniq_ptr_data<int, std::default_delete<int []>, true, true>::__uniq_ptr_data()’
  530 |  : _M_t()
      |         ^
/usr/include/c++/10/bits/unique_ptr.h:209:40: note: candidate: ‘std::__uniq_ptr_data<int, std::default_delete<int []>, true, true>::__uniq_ptr_data(std::__uniq_ptr_impl<int, std::default_delete<int []> >::pointer) [inherited from std::__uniq_ptr_impl<int, std::default_delete<int []> >]’
  209 |       using __uniq_ptr_impl<_Tp, _Dp>::__uniq_ptr_impl;
      |                                        ^~~~~~~~~~~~~~~
/usr/include/c++/10/bits/unique_ptr.h:209:40: note:   candidate expects 1 argument, 0 provided
/usr/include/c++/10/bits/unique_ptr.h:209:40: note: candidate: ‘template<class _Del> std::__uniq_ptr_data<int, std::default_delete<int []>, true, true>::__uniq_ptr_data(std::__uniq_ptr_impl<int, std::default_delete<int []> >::pointer, _Del&&) [inherited from std::__uniq_ptr_impl<int, std::default_delete<int []> >]’
/usr/include/c++/10/bits/unique_ptr.h:209:40: note:   template argument deduction/substitution failed:
/usr/include/c++/10/bits/unique_ptr.h:530:9: note:   candidate expects 2 arguments, 0 provided
  530 |  : _M_t()
      |         ^
/usr/include/c++/10/bits/unique_ptr.h:210:7: note: candidate: ‘std::__uniq_ptr_data<_Tp, _Dp, <anonymous>, <anonymous> >::__uniq_ptr_data(std::__uniq_ptr_data<_Tp, _Dp, <anonymous>, <anonymous> >&&) [with _Tp = int; _Dp = std::default_delete<int []>; bool <anonymous> = true; bool <anonymous> = true]’
  210 |       __uniq_ptr_data(__uniq_ptr_data&&) = default;
      |       ^~~~~~~~~~~~~~~
/usr/include/c++/10/bits/unique_ptr.h:210:7: note:   candidate expects 1 argument, 0 provided
make: *** [Makefile.common:33: f4/res-moninfo-dense.o] Error 1
make: Leaving directory '/home/dan/src/M2/M2/BUILD/dan/builds.tmp/fedora-release-1.15/Macaulay2/e'

Compilation exited abnormally with code 2 at Wed Jun  3 06:12:25

[mahrud]

@jkyang92 figured this out. fflas-ffpack is adding -fabi-version=6 that messes things up. One way would be to remove this line:

M2/M2/configure.ac

Line 1171 in 99b7b7e

FFLAS_FFPACK_CXXFLAGS=`fflas-ffpack-config --cflags 2>&1`

[mahrud]

Also, this seems to happen with gcc 10 on any system, not necessarily Fedora.

Oh, givaro also adds that flag. And they both add the --std= flag, which is fine if we compile them (as they get the flag from the flags we give them), but if they're installed on the system, they cause issues when there's a mismatch.

[DanGrayson]

This does indeed fix it, thanks for the tip! I think I'll fix it by simply adding -fabi-version=0 to the end of the line.

[mahrud]

That's still confusing, since there will be multiple -fabi-version flags in the compile command. Is the issue of the mismatching --std resolved?

[DanGrayson]

The second -std= on the line is ours, so it will override the first one, which is givaro's. Actually, now it seems to me we should just ignore givaro's cflags altogether, which might be intended for compiling givaro itself, not programs using givaro.

Here is its pkgconfig file:

/------------------ givaro.pc ------------------------
prefix=/home/dan/src/M2/M2/BUILD/dan/builds.tmp/fedora-release-1.15/usr-host
exec_prefix=/home/dan/src/M2/M2/BUILD/dan/builds.tmp/fedora-release-1.15/usr-host
libdir=/home/dan/src/M2/M2/BUILD/dan/builds.tmp/fedora-release-1.15/usr-host/lib
includedir=/home/dan/src/M2/M2/BUILD/dan/builds.tmp/fedora-release-1.15/usr-host/include

Name: Givaro
Description: C++ library for arithmetic and algebraic computations
URL: http://givaro.forge.imag.fr
Version: 4.0.2
Requires:
Libs: -L${exec_prefix}/lib -lgivaro  -lgmpxx -lgmp
Cflags: -I${prefix}/include  -std=gnu++11 -g3 -O2 -Wno-mismatched-tags -w   -fabi-version=6
\-------------------------------------------------------

[DanGrayson]

I'll try changing the line you pointed to to

     FFLAS_FFPACK_CXXFLAGS=`fflas-ffpack-config --cflags-only-I 2>&1`

[mahrud]

The flags are necessary for older versions of gcc, and this solution wasn't viable for CMake. However, it turned out that this has been fixed in the upstream of fflas_ffpack (linbox-team/fflas-ffpack#305) and givaro (linbox-team/givaro#151) very recently, so I just updated the respective submodules in 82d78a6.

[mahrud]

@d-torrance could you fix this in the debian packages of fflas-ffpack and givaro? Since the default gcc version is above 5, the pkg-config files shouldn't have -fabi-version.

[d-torrance]

@d-torrance could you fix this in the debian packages of fflas-ffpack and givaro? Since the default gcc version is above 5, the pkg-config files shouldn't have -fabi-version.

Is there a reason to get the change in now and not just wait to package the next upstream release?

It doesn't look like we're getting -fabi-version from either, at least in the autotools build. For givaro, we call it with the --cflags-only-I option. And we're doing something simliar for fflas-ffpack:

M2/M2/configure.ac

Line 1161 in 818b61c

FFLAS_FFPACK_CXXFLAGS=$(for x in $(fflas-ffpack-config --cflags 2>&1) ; do case $x in (-I*) echo -n "$x " ;; esac done)

(This probably could get simplified to use pkg-config just like givaro...)

[mahrud]

The reason why we're not using pkg-config is that it would insert this erroneous flag, which breaks compiling with gcc10 and clang10. One good reason to do it now rather than wait is that gcc10 and clang10 are now available on ubuntu-20. The CMake build also can't use the packaged versions because of this flag.

…

On Fri, Jul 10, 2020, 8:33 AM Doug Torrance ***@***.***> wrote: @d-torrance <https://github.com/d-torrance> could you fix this in the debian packages of fflas-ffpack and givaro? Since the default gcc version is above 5, the pkg-config files shouldn't have -fabi-version. Is there a reason to get the change in now and not just wait to package the next upstream release? It doesn't look like we're getting -fabi-version from either, at least in the autotools build. For givaro, we call it with the --cflags-only-I option. And we're doing something simliar for fflas-ffpack: https://github.com/Macaulay2/M2/blob/818b61cb76df7035f6011ed860d0024fcd91e6f8/M2/configure.ac#L1161 (This probably could get simplified to use pkg-config just like givaro...) — You are receiving this because you modified the open/close state. Reply to this email directly, view it on GitHub <#1227 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAYAPRXXWBPCLBMHN7AXURDR24KCPANCNFSM4NR4R2CA> .

[mahrud]

Also, on Fedora the RPM packages don't include -fabi-version=6; instead, they have -lopenblasp.

[mahrud]

There's a new release of givaro and fflas-ffpack.

[dimpase]

The reason why we're not using pkg-config is that it would insert this erroneous flag,

pkg-config does not "insert" anything by itself. M2 inserted cflags it emits, in error. pkg-config allows one to get variables set in the configuration, via pkg-config --variable=<varname> <modname>, something which can be processed further if needed.