Question 46713 in Debian Question posted in
The oficial documentation can be found here.

problem installing nloptr 2.0.0 on debian 9 with R 4.2.0 and cmake 3.23.1

on my machine debian 9 (stretch), i have installed R4.2.0 from source.
i have problem to install nloptr 2.0.0 using syntax:

if (!require("nloptr", quietly = TRUE)) BiocManager::install("nloptr")

the error i get is:

/opt/R/4.2.0/lib/R/etc/Makeconf:177: recipe for target 'test-C-API.o' failed
make: *** [test-C-API.o] Error 1
ERROR: compilation failed for package ‘nloptr’
* removing ‘/home/ezop/R/x86_64-pc-linux-gnu-library/4.2/nloptr’

The downloaded source packages are in
    ‘/tmp/Rtmpqk35gk/downloaded_packages’
Warning message:
In install.packages(...) :
  installation of package ‘nloptr’ had non-zero exit status

I have tried, also, to install it by copying compiled binaries i have found online, but then i have this error:

> library(nloptr)
Error: package or namespace load failed for ‘nloptr’ in dyn.load(file, DLLpath = DLLpath, ...):
 unable to load shared object '/home/ezop/R/x86_64-pc-linux-gnu-library/4.2/nloptr/libs/nloptr.so':
  /home/ezop/R/x86_64-pc-linux-gnu-library/4.2/nloptr/libs/nloptr.so: invalid ELF header

I have checked the header and machine info, but i dont know what to do next:

base) root@kanta:/home/ezop/R/x86_64-pc-linux-gnu-library/4.2# file /home/ezop/R/x86_64-pc-linux-gnu-library/4.2/nloptr/libs/nloptr.so
/home/ezop/R/x86_64-pc-linux-gnu-library/4.2/nloptr/libs/nloptr.so: Mach-O 64-bit x86_64 dynamically linked shared library, flags:<NOUNDEFS|DYLDLINK|TWOLEVEL|WEAK_DEFINES|BINDS_TO_WEAK|NO_REEXPORTED_DYLIBS|HAS_TLV_DESCRIPTORS>
(base) root@kanta:/home/ezop/R/x86_64-pc-linux-gnu-library/4.2# uname -a
Linux kanta 4.9.0-18-amd64 #1 SMP Debian 4.9.303-1 (2022-03-07) x86_64 GNU/Linux
Tags:

2

Answers


  1. 0

    I was having the same problem a few minutes ago. I tried installing cmake and gfortran but with little success. I noticed, when I was trying install.packages("nloptr") for the last time, this error message: There are binary versions available but the source versions are later. Do you want to install from sources the package which needs compilation?.

    Jenny Bryan explains here that a simple "No" would do.

    I hope this is useful for you too.

    Login or Signup to reply.
  2. 0

    I just stumbled on this same problem under
    R version 4.1.1 (2021-08-10)
    Platform: x86_64-pc-linux-gnu (64-bit)

    I do not have nlopt installed on my Linux system but do have cmake/3.17.3

    As such, during the install of nloptr_2.0.3

    install.packages('nloptr')

    we see pkg-config could not find nlopt so it checked for cmake to remake nlopt from source:

    checking for pkg-config... /usr/bin/pkg-config
checking if pkg-config knows NLopt... no    
checking for cmake... /software/cgeh/cmake/cmake-3.17.3/bin/cmake

    and errored out with

    make: *** [/software/cgeh/r/4.1.1/install/lib64/R/etc/Makeconf:177: test-C-API.o] Error 1
ERROR: compilation failed for package  nloptr

    due to an ambiguous overloaded function match for the function abs()

    test-C-API.cpp:107:35: error: call of overloaded   abs(__gnu_cxx::__alloc_traits<std::allocator<double> >::value_type) 
    is ambiguous expect_true(abs(res[0] - 1./ 3) < 1.0e-4);

    If you ungzip and untar the source code (nloptr.tar.gz) and look in the file src/test-C-API.cpp you can see the call to expect_true() in context:

    test_that("Test exposed NLopt C code using example from NLopt tutorial")
   {
     // Get optimal x values.
    std::vector<double> res = solve_example();

    // Check return value.
    expect_true(res.size() == 2);
    expect_true(abs(res[0] - 1./ 3) < 1.0e-4); 
    expect_true(abs(res[1] - 8./27) < 1.0e-4); 
  }
}

    where the argument of abs() is ‘double’ but looking more closely into the error messages from the R install attempt, it appears that the only candidate function declarations for abs() are for input types int or long int, not ‘double’

    /usr/include/stdlib.h:735:12: note: candidate: int abs(int)
/usr/include/c++/6.2.1/cstdlib:185:3: note: candidate: __int128 std::abs(__int128)
/usr/include/c++/6.2.1/cstdlib:180:3: note: candidate: long long int std::abs(long long int)
/usr/include/c++/6.2.1/cstdlib:172:3: note: candidate: long int std::abs(long int)

    In my case, it seems that the set of included libraries do not include a library where abs() is defined for floating-point types, for example cmath. In my case, cmath is in /usr/include/c++/6.2.1/ though including it in test-C-API.h as

    #include <cmath>

    did not resolve the problem – I am not familiar with the Catch unit testing library or testthat() functions so do not have an idea why this fix attempt failed. Perhaps others can chime in with an alternate fix involving cmath.

    My work around instead was to edit test-C-API.cpp to comment out the two lines in the final test_that() that rely on abs(double), beginning with "expect_true(abs(res[...", save it, then tar and gzip the whole directory tree back again and then install using this local now edited file:

    install.packages("nloptr.tar.gz", repos = NULL, type="source")

    The installation proceeded as expected and my test R code gave me the desired results. I do not anticipate that my R code will have a problem with abs(), only that the unit tests in C++ they wrote did under my system setting.

    Login or Signup to reply.
Please signup or login to give your own answer.

Back To Top
Search