Package Details: cado-nfs-git 20241219.cb69f536e-1

Git Clone URL: https://aur.archlinux.org/cado-nfs-git.git (read-only, click to copy)
Package Base: cado-nfs-git
Description: Implementation of the Number Field Sieve (NFS) algorithm for factoring integers
Upstream URL: http://cado-nfs.gforge.inria.fr/
Licenses: LGPL2
Conflicts: cado-nfs
Provides: cado-nfs
Submitter: jdetrey
Maintainer: AquilaIrreale
Last Packager: AquilaIrreale
Votes: 4
Popularity: 0.000547
First Submitted: 2015-12-07 12:57 (UTC)
Last Updated: 2024-12-29 22:33 (UTC)

Dependencies (14)

Required by (0)

Sources (2)

Latest Comments

« First ‹ Previous 1 2 3 4 Next › Last »

gilcu3 commented on 2022-09-24 21:50 (UTC) (edited on 2022-09-26 09:16 (UTC) by gilcu3)

@AquilaIrreale The output is empty for that command. The PKGBUILD is somehow registering the files in the local folder and not in the global one.

EDIT: For some reason the behavior changes depending on which folder I build the package, maybe a bug related to the buildsystem. The problem seems to be the PREFIX variable, that for some reason is not setup properly. Addidng export PREFIX=/usr before the make command fixes the issue for me.

AquilaIrreale commented on 2022-09-24 21:01 (UTC) (edited on 2022-09-24 21:10 (UTC) by AquilaIrreale)

@gilcu3 what do you mean? make install puts both cado-nfs.py and cado-nfs-client.py under /usr/bin (which should most definitely be in your $PATH).

Could you please post the output of

pacman -Qql cado-nfs-git | grep '^/usr/bin'

just to make sure?

gilcu3 commented on 2022-09-24 09:44 (UTC) (edited on 2022-09-24 09:44 (UTC) by gilcu3)

@AquilaIrreale Thank for the fix.

In the current version of the package you are running make install, but not the specific install commands for the executables, so the cado-nfs.py file is not ending up in the global path.

AquilaIrreale commented on 2022-09-23 18:27 (UTC)

@gilcu3 fixed it as you suggested by adding a patch to disable detection of system-installed fmt version.

I did not have Arch's fmt on my system so for me it was already using its own bundled version automatically and I never noticed the incompatibility, so thank you for reporting the issue.

gilcu3 commented on 2022-09-21 08:14 (UTC) (edited on 2022-09-21 09:21 (UTC) by gilcu3)

Currently, the package is not building due to an error. A patch like the one mentioned in here It seems to be related to incompatibility with the current version of fmt. Using the bundled one is an option in the original package, so we could take that path


[ 89%] Built target matmul_p_13_zone
[ 89%] Building CXX object linalg/bwc/CMakeFiles/lingen_u64k1.dir/lingen_bigmatpoly_ft.cpp.o
[ 89%] Building CXX object linalg/bwc/CMakeFiles/lingen_u64k1.dir/lingen_qcode_binary.cpp.o
[ 89%] Linking CXX static library libmatmul_p_14_zone.a
[ 89%] Built target matmul_p_14_zone
[ 89%] Building CXX object linalg/bwc/CMakeFiles/lingen_verify_checkpoints_p_1.dir/lingen_verify_checkpoints.cpp.o
[ 89%] Building CXX object linalg/bwc/CMakeFiles/lingen_verify_checkpoints_p_2.dir/lingen_verify_checkpoints.cpp.o
In file included from /home/rey/.cache/aurutils/sync/cado-nfs-git/src/cado-nfs/linalg/bwc/lingen_tuning.cpp:25:
/usr/include/fmt/core.h: In instantiation of ‘constexpr fmt::v9::detail::value<Context> fmt::v9::detail::make_value(T&&) [with Context = fmt::v9::basic_format_context<fmt::v9::appender, char>; T = const lingen_call_companion::key&]’:
/usr/include/fmt/core.h:1777:29:   required from ‘constexpr fmt::v9::detail::value<Context> fmt::v9::detail::make_arg(T&&) [with bool IS_PACKED = true; Context = fmt::v9::basic_format_context<fmt::v9::appender, char>; type <anonymous> = fmt::v9::detail::type::custom_type; T = const lingen_call_companion::key&; typename std::enable_if<IS_PACKED, int>::type <anonymous> = 0]’
/usr/include/fmt/core.h:1901:77:   required from ‘constexpr fmt::v9::format_arg_store<Context, Args>::format_arg_store(T&& ...) [with T = {std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >&, const unsigned int&, const lingen_call_companion::key&}; Context = fmt::v9::basic_format_context<fmt::v9::appender, char>; Args = {std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >, unsigned int, lingen_call_companion::key}]’
/usr/include/fmt/core.h:1918:31:   required from ‘constexpr fmt::v9::format_arg_store<Context, typename std::remove_cv<typename std::remove_reference<Args>::type>::type ...> fmt::v9::make_format_args(Args&& ...) [with Context = basic_format_context<appender, char>; Args = {std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >&, const unsigned int&, const lingen_call_companion::key&}]’
/usr/include/fmt/core.h:3206:44:   required from ‘std::string fmt::v9::format(format_string<T ...>, T&& ...) [with T = {std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >&, const unsigned int&, const lingen_call_companion::key&}; std::string = std::__cxx11::basic_string<char>; format_string<T ...> = basic_format_string<char, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >&, const unsigned int&, const lingen_call_companion::key&>]’
/home/rey/.cache/aurutils/sync/cado-nfs-git/src/cado-nfs/linalg/bwc/lingen_tuning.cpp:1281:45:   required from here
/usr/include/fmt/core.h:1757:7: error: static assertion failed: Cannot format an argument. To make type T formattable provide a formatter<T> specialization: https://fmt.dev/latest/api.html#udt
 1757 |       formattable,
      |       ^~~~~~~~~~~
/usr/include/fmt/core.h:1757:7: note: ‘formattable’ evaluates to false
[ 90%] Building CXX object linalg/bwc/CMakeFiles/lingen_verify_checkpoints_p_3.dir/lingen_verify_checkpoints.cpp.o
make[2]: *** [linalg/bwc/CMakeFiles/lingen_u64k1.dir/build.make:104: linalg/bwc/CMakeFiles/lingen_u64k1.dir/lingen_tuning.cpp.o] Error 1
make[2]: *** Waiting for unfinished jobs....
[ 90%] Building CXX object linalg/bwc/CMakeFiles/lingen_verify_checkpoints_p_4.dir/lingen_verify_checkpoints.cpp.o
[ 90%] Building CXX object linalg/bwc/CMakeFiles/lingen_verify_checkpoints_p_5.dir/lingen_verify_checkpoints.cpp.o
[ 90%] Linking CXX executable lingen_verify_checkpoints_u64k1
[ 90%] Built target lingen_verify_checkpoints_u64k1
[ 90%] Building CXX object linalg/bwc/CMakeFiles/lingen_verify_checkpoints_p_6.dir/lingen_verify_checkpoints.cpp.o
[ 90%] Building CXX object linalg/bwc/CMakeFiles/lingen_verify_checkpoints_p_7.dir/lingen_verify_checkpoints.cpp.o
make[1]: *** [CMakeFiles/Makefile2:5980: linalg/bwc/CMakeFiles/lingen_u64k1.dir/all] Error 2
make[1]: *** Waiting for unfinished jobs....
[ 90%] Linking CXX executable lingen_verify_checkpoints_p_2
[ 90%] Linking CXX executable lingen_verify_checkpoints_p_1
[ 90%] Built target lingen_verify_checkpoints_p_2
[ 90%] Built target lingen_verify_checkpoints_p_1
[ 90%] Linking CXX executable lingen_verify_checkpoints_p_3
[ 90%] Built target lingen_verify_checkpoints_p_3
[ 90%] Linking CXX executable lingen_verify_checkpoints_p_4
[ 90%] Built target lingen_verify_checkpoints_p_4
[ 90%] Linking CXX executable lingen_verify_checkpoints_p_5
[ 90%] Built target lingen_verify_checkpoints_p_5
[ 90%] Linking CXX executable lingen_verify_checkpoints_p_6
[ 90%] Linking CXX executable lingen_verify_checkpoints_p_7
[ 90%] Built target lingen_verify_checkpoints_p_6
[ 90%] Built target lingen_verify_checkpoints_p_7
make: *** [Makefile:146: all] Error 2
make: *** [Makefile:7: all] Error 2

ccorn commented on 2021-08-15 23:16 (UTC) (edited on 2021-08-15 23:17 (UTC) by ccorn)

From what I get to see of CMake files like avx2.cmake, the configuration goes as follows:

  1. Try to compile code for specific SIMD datatypes like avx2.c without adding own compiler flags.
  2. If compilation fails, check for -march.
  3. If no -march is specified, try adding flags like -mavx2.
  4. If compilation succeeds, try running the program on the build machine.
  5. If compilation or running fails, clear/unset the associated configuration variable like HAVE_AVX2.
  6. If running succeeds, set the associated configuration variable.

Thus, Haswell users should find HAVE_AVX2 defined in their cado_config.h, but Sandybridge users not.

To conclude, both the specified -march and the capabilities of the build system limit the available SIMD features: You cannot activate code paths meant for a target architecture more recent than that of your build system.

Worse, if you specify an architecture that is incompatible with your build system, then those incompatibilities may lead to failure of the autodetection of even those SIMD features that your build machine actually supports.

Thus, the only safe choices are

  • A minimum architecture that both build and target system can be expected to support, e.g. -march=sandybridge,
  • -march=native for the feature set of the build machine,
  • equivalently, no -march at all. Compared to -march=native, this adds more detailed compiler flags, but the HAVE_* definitions are identical.

ccorn commented on 2021-08-15 19:07 (UTC)

I wonder why _march=haswell does not result in the definition of HAVE_AVX2 in (my) cado_config.h. Does anyone achieve HAVE_AVX2 with _march=native?

ccorn commented on 2021-08-15 18:48 (UTC)

Anyhow, this is the resulting cado_config.h, looking about right I think

Yes, that matches mine. Interestingly, setting _march=haswell on my sandybridge produces the same cado_config.h (except for the C*FLAGS strings of course), but results in incompatible binaries.