I'm attempting to build a CRAN package and I'm getting a strange error when I try to 'Check' my package in RStudio, here is the message:
==> devtools::check(document = FALSE)
-- Building ----------------------------------------------------------------------- TDAInference --
Setting env vars:
* CFLAGS : -Wall -pedantic -fdiagnostics-color=always
* CXXFLAGS : -Wall -pedantic -fdiagnostics-color=always
* CXX11FLAGS: -Wall -pedantic -fdiagnostics-color=always
* CXX14FLAGS: -Wall -pedantic -fdiagnostics-color=always
* CXX17FLAGS: -Wall -pedantic -fdiagnostics-color=always
* CXX20FLAGS: -Wall -pedantic -fdiagnostics-color=always
---------------------------------------------------------------------------------------------------
v checking for file 'C:\Users\User\Documents\TDAInference/DESCRIPTION' ...
- preparing 'TDAInference':
v checking DESCRIPTION meta-information ...
- installing the package to build vignettes
-----------------------------------
- installing *source* package 'TDAInference' ...
** using staged installation
** R
** byte-compile and prepare package for lazy loading
** help
*** installing help indices
converting help for package 'TDAInference'
finding HTML links ... done
TDAInference html
diagram_distance html
diagram_to_df html
loss html
permutation_test html
** building package indices
** installing vignettes
** testing if installed package can be loaded from temporary location
Error: package or namespace load failed for 'TDAInference' in library.dynam(lib, package, package.lib):
DLL 'TDAInference' not found: maybe not installed for this architecture?
Has anyone had a similar problem before? Any suggestions of fixes this would be much appreciated!!
Posting because I lost half a day on this ^^'
I had a similar issue because I removed all my c++ code.
However, I had remove the Rcpp import/dpends in my DESCRIPTION file, but that just added the error of a missing dependency in that file...
After finding this page, I grep "Rcpp" to see where the hell it was left in and realized that I still had the [packagename]-package.Rfile ^^' which contained:
## usethis namespace: start
#' #importFrom Rcpp sourceCpp
#' #useDynLib [packagename], .registration = TRUE
## usethis namespace: end
NULL
So yeah, if you don't have c++ code/removed it, make sure your package structure matches ^^'
I figured out the problem. Basically I was trying to borrow file structure from another package which included C code. Seeing as my package has no C code I had some extra lines of code in my Description file (in particular, the useDynLib function). Once I removed that line everything worked perfectly.
Related
I'm creating a Dockerfile for my Rust package, following the example shown here: https://alexbrand.dev/post/how-to-package-rust-applications-into-minimal-docker-containers/
FROM rust:1.47.0 AS build
WORKDIR /usr/src
RUN rustup target add x86_64-unknown-linux-musl
RUN apt-get update
RUN apt-get install cmake musl-tools clang libc++-dev build-essential autoconf libtool pkg-config
# Create a dummy project and build the app's dependencies.
# If the Cargo.toml or Cargo.lock files have not changed,
# we can use the docker build cache and skip these (typically slow) steps.
RUN USER=root cargo new mypackage
WORKDIR /usr/src/mypackage
COPY Cargo.toml build.rs ./
COPY .git ./.git
RUN cargo build --release
# Copy the source and build the application.
COPY src ./src
RUN cargo install --target x86_64-unknown-linux-musl --path .
However, it fails at the step with cargo install, which appears to be because it's unable to find musl-g++. That seems strange.
Am I misunderstanding the error? I'm a bit lost as to how to move forward with this.
Here is the entire message:
Step 12/16 : RUN cargo install --target x86_64-unknown-linux-musl --path .
---> Running in d861b7efa994
...
error: failed to run custom build command for `libmimalloc-sys v0.1.18`
Caused by:
process didn't exit successfully: `/usr/src/mypackage/target/release/build/libmimalloc-sys-9ec3b6c9ac1c8d9d/build-script-build` (exit code: 101)
--- stdout
running: "cmake" "/usr/local/cargo/registry/src/github.com-1ecc6299db9ec823/libmimalloc-sys-0.1.18/c_src/mimalloc" "-DMI_OVERRIDE=OFF" "-DMI_BUILD_TESTS=OFF" "-DMI_SECURE=OFF" "-DMI_LOCAL_DYNAMIC_TLS=OFF" "-Dmi_defines=MI_DEBUG=0" "-DCMAKE_INSTALL_PREFIX=/usr/src/mypackage/target/x86_64-unknown-linux-musl/release/build/libmimalloc-sys-ea7ff527a98597ef/out" "-DCMAKE_C_FLAGS= -ffunction-sections -fdata-sections -fPIC -m64" "-DCMAKE_C_COMPILER=/usr/bin/musl-gcc" "-DCMAKE_CXX_FLAGS= -ffunction-sections -fdata-sections -fPIC -m64" "-DCMAKE_CXX_COMPILER=musl-g++" "-DCMAKE_ASM_FLAGS= -ffunction-sections -fdata-sections -fPIC -m64" "-DCMAKE_ASM_COMPILER=/usr/bin/musl-gcc" "-DCMAKE_BUILD_TYPE=Release"
-- The C compiler identification is GNU 8.3.0
-- The CXX compiler identification is unknown
-- Check for working C compiler: /usr/bin/musl-gcc
-- Check for working C compiler: /usr/bin/musl-gcc -- works
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Detecting C compile features
-- Detecting C compile features - done
-- Configuring incomplete, errors occurred!
See also "/usr/src/mypackage/target/x86_64-unknown-linux-musl/release/build/libmimalloc-sys-ea7ff527a98597ef/out/build/CMakeFiles/CMakeOutput.log".
See also "/usr/src/mypackage/target/x86_64-unknown-linux-musl/release/build/libmimalloc-sys-ea7ff527a98597ef/out/build/CMakeFiles/CMakeError.log".
--- stderr
CMake Error at CMakeLists.txt:2 (project):
The CMAKE_CXX_COMPILER:
musl-g++
is not a full path and was not found in the PATH.
Tell CMake where to find the compiler by setting either the environment
variable "CXX" or the CMake cache entry CMAKE_CXX_COMPILER to the full path
to the compiler, or to the compiler name if it is in the PATH.
thread 'main' panicked at '
command did not execute successfully, got: exit code: 1
build script failed, must exit now', /usr/local/cargo/registry/src/github.com-1ecc6299db9ec823/cmake-0.1.45/src/lib.rs:894:5
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
warning: build failed, waiting for other jobs to finish...
error: failed to compile `mypackage v0.1.0 (/usr/src/mypackage)`, intermediate artifacts can be found at `/usr/src/mypackage/target`
Caused by:
build failed
I would start by running the base image only interactively and look for musl-g++. If not found, add the installation to the Dockerfile and try again.
I am trying to compile a code with gfortran. One of the first things that happens in the compilation is the creation of constants.mod. Soon after that gfortran tells me:
Fatal Error: Cannot read module file ‘constants.mod’ opened at (1), because it was created by a different version of GNU Fortran
Now here's the thing: This module file is created by the same gfortran that it's trying to read it. gfortran creates the thing itself and then 1 second later thinks the file was created by some other version! Any idea what's going on here?
You'll probably want to see the compile command:
mpif90 -c -O3 -ISDF/FORTRAN/include -I/usr/include -Iobj -Jobj -o obj/shared_data.o src/core/shared_data.F90
shared_data.F90 contains the module constants at the top of the file.
EDIT: Here's the compile command followed by the full error message:
$> mpif90 -c -O3 -ISDF/FORTRAN/include -I/usr/include -Iobj -Jobj -o obj/shared_data.o src/core/shared_data.F90
src/core/shared_data.F90:67:6:
USE constants
1
Fatal Error: Cannot read module file ‘constants.mod’ opened at (1), because it was created by a different version of GNU Fortran
compilation terminated.
UPDATE: I hope you'll agree this is weird. The file that is failing is in src/core. If I cd to src/core and issue this command:
mpif90 -c -O3 -I../../SDF/FORTRAN/include -I../../obj -J../../obj -o ../../obj/shared_data.o shared_data.F90
it compiles just fine! But then I clean everything out of the obj directory and I cd two levels up and issue:
mpif90 -c -O3 -ISDF/FORTRAN/include -Iobj -Jobj -o shared_data.o src/core/shared_data.F90
and it fails with the error I showed above! What is the difference??? Thanks.
I'm trying to compile and run a fortran 90 code with gfortran on a windows 7 machine.
When I compile and link using
gfortran -I"myDir" -g -Wall -Wextra -pedantic -fimplicit-none -fbacktrace -fcheck=all -Wuninitialized
-Q -J"bin" parametricStudy.f90 -o LDCP
I get the following error:
Fatal Error: Can't rename module file 'bin/initializeubcs_mod.mod0' to 'bin/init
ializeubcs_mod.mod': File exists
If I delete the mod file in the folder 'bin', then it compiles without any problems, but I don't want to have to delete all of my .mod files in the folder every time I compile my code. What should I do?
Any help is greatly appreciated!
If you're using gfortran 4.9 or 4.9.1 I guess you're being bit by https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62215 . In that case, please update to 4.9.2 where this issue is fixed.
This is to compile and link a static library (so only a build time dependency) that the source is fetched from a repository (just like the source of the main program) on a ubuntu launchpad build bot.
currently i am doing:
#!/usr/bin/make -f
export PREFIX=/usr
export CFLAGS= -O3 -fomit-frame-pointer -flto -fwhole-program
export CXXFLAGS= -O3 -fomit-frame-pointer -flto -fwhole-program
%:
dh $#
override_dh_auto_configure:
cd src/munt;cmake -DCMAKE_CXX_FLAGS="-O3 -fomit-frame-pointer -flto" mt32emu;make;make install
#...compile of the program that depends on mt32emu...
But it fails with:
Install the project...
-- Install configuration: ""
-- Installing: /usr/local/lib/libmt32emu.a
CMake Error at cmake_install.cmake:36 (FILE):
file INSTALL cannot copy file
"/tmp/buildd/dosbox-0.74+20121225/src/munt/libmt32emu.a" to
"/usr/local/lib/libmt32emu.a".
make[2]: *** [install] Error 1
make[2]: Leaving directory `/tmp/buildd/dosbox-0.74+20121225/src/munt'
make[1]: *** [override_dh_auto_configure] Error 2
make[1]: Leaving directory `/tmp/buildd/dosbox-0.74+20121225'
make: *** [build] Error 2
dpkg-buildpackage: error: debian/rules build gave error exit status 2
E: Failed autobuilding of package
I: unmounting /var/cache/pbuilder/ccache filesystem
I: unmounting dev/pts filesystem
I: unmounting proc filesystem
I: cleaning the build env
I: removing directory /var/cache/pbuilder/build//2751 and its subdirectories
The idea is to install a static library dependency that is is not packaged in the ubuntu repositories in the launchpad pbuilder env, so it can be used as if it was a system dependency already.
If i try to do 'sudo make install' (and add sudo to the build-deps in debian/control), it asks me for the 'pbuilder' password when testing locally, which i'm assuming will hang the machine on the ubuntu buildbots.
edit: it actually fails on the buildbots because 'no tty present and no askpass program specified'.
There are several things you can do to clean up your rules file, especially when you are using dh.
In the % target, all of the dh command take a parameter builddirectory, which specifies what directory you are building in. This tells the builder to cd to that directory and then call commands (make, cmake, etc.).
In addition, you should just let dh install the files for you. This is done automatically. You shouldn't have to call make install manually.
Here's a slightly easier-to-read rules file:
#!/usr/bin/make -f
export PREFIX=/usr
export CFLAGS= -O3 -fomit-frame-pointer -flto -fwhole-program
export CXXFLAGS= -O3 -fomit-frame-pointer -flto -fwhole-program
%:
dh $# --builddirectory=src/munt
override_dh_auto_configure:
cd src/munt && cmake -DCMAKE_CXX_FLAGS="-O3 -fomit-frame-pointer -flto" mt32emu
#...compile of the program that depends on mt32emu...
Is this just a permissions issue? (i.e. -- must use 'sudo' to install to '/usr/local'?)
Must you install it to '/usr/local'?
If it's just a static library, purely needed for the build of the "the program that depends on mt32emu" then you could put it anywhere, and just tell the dependent program where it is.
To install somewhere else, use -DCMAKE_INSTALL_PREFIX=/directory/where/you/have/write/privileges. Or use DESTDIR= with the make install.
I eventually 'solved' this by depending on launchpad repository dependencies, that is, building a whole package for the library and building that on launchpad and then importing the archive where that was placed to my other builds. Made it explicit i guess.
I'm trying to add DKMS support in a kernel module i'm working on.
I have placed the kernel module source with a static lib to be linked against in the following directory:
/usr/src/dpx/1.0
With the following files:
dkms.conf
Makefile
dpxmtt.c
lib.a
dkms.conf file is like this:
MAKE="make"
CLEAN="make clean"
BUILT_MODULE_NAME=dpx
BUILT_MODULE_LOCATION=src/
DEST_MODULE_LOCATION=/kernel/drivers/input/touchscreen
PACKAGE_NAME=dpxm
PACKAGE_VERSION=1.0
REMAKE_INITRD=yes
And the makefile is like this:
EXTRA_CFLAGS+=-DLINUX_DRIVER -mhard-float
obj-m += dpx.o
dpx-objs:= dpxmtt.o ../source/lib.a
all:
make -C /lib/modules/$(shell uname -r)/build M=$(PWD) modules
clean:
make -C /lib/modules/$(shell uname -r)/build M=$(PWD) clean
The ../source/lib.a is an hack since when the makefile is invoked by the dkms building system it was saying that it couldn't be found in directory (the build directory), but since it was being copied to the source directory, i'm referencing it relatively.
When I call
sudo dkms build -m dpx -v 1.0
The result is almost perfect:
santos#NS-PC:~$ sudo dkms build -m dpx -v 1.0
Kernel preparation unnecessary for this kernel. Skipping...
Building module:
cleaning build area....
make KERNELRELEASE=3.0.0-14-generic....
ERROR (dkms apport): binary package for dpx: 1.0 not found
Error! Build of dpx.ko failed for: 3.0.0-14-generic (i686)
Consult the make.log in the build directory
/var/lib/dkms/dpx/1.0/build/ for more information.
nsantos#NS-PC:~$
And the content of the log file is:
DKMS make.log for dpx-1.0 for kernel 3.0.0-14-generic (i686)
Thu Jan 19 11:07:54 WET 2012
make -C /lib/modules/3.0.0-14-generic/build M=/var/lib/dkms/dpx/1.0/build modules
make[1]: Entering directory `/usr/src/linux-headers-3.0.0-14-generic'
CC [M] /var/lib/dkms/dpx/1.0/build/dpxmtt.o
LD [M] /var/lib/dkms/dpx/1.0/build/dpx.o
Building modules, stage 2.
MODPOST 1 modules
CC /var/lib/dkms/dpx/1.0/build/dpx.mod.o
LD [M] /var/lib/dkms/dpx/1.0/build/dpx.ko
make[1]: Leaving directory `/usr/src/linux-headers-3.0.0-14-generic'
The module was built correctly but it ends with the error:
ERROR (dkms apport): binary package for dpx: 1.0 not found
Error! Build of dpx.ko failed for: 3.0.0-14-generic (i686)
And I don't know what it means. Does anybody know?
Using:
$(shell uname -r)
in the Makefile it might be also wrong! The "shell uname -r" refers to the currently running kernel, but the main reason to use the dkms it's because it offers an automated method to recompile the kernel modules that reside outside of the kernel tree for every newly installed kernel. What i mean is that the Makefile might refers to a different kernel which the dkms is building the module for.
Use:
${kernelver} instead.
I had a similar problem. I think your BUILT_MODULE_LOCATION is set incorrectly to the src directory. It should be set in your example to the current directory, or you can just omit this variable and dkms would default to the current directory.