found staticlib std instead of rlib or dylib
help: please recompile that crate using --crate-type lib
note: the following crate versions were found:
crate std: C:\Users.rustup/toolchains/stable-x86_64-pc-windows-msvc\lib\rustlib\x86_64-pc-windows-msvc\lib\std-77c29e3b2a96c9a6.dll.librustc(E0462)
found staticlib std instead of rlib or dylib
help: please recompile that crate using --crate-type lib
note: the following crate versions were found:
crate std: C:\Users.rustup/toolchains/stable-x86_64-pc-windows-msvc\lib\rustlib\x86_64-pc-windows-msvc\lib\std-77c29e3b2a96c9a6.dll.librustc(E0462)
How to recompile that crate using --crate-type lip ?
I am doing https://docs.substrate.io/tutorials/v3/kitties/pt1/
Related
In the OpenBLAS root directory on a linux system, with emcc sdk already loaded by (in the emsdk directory, source ./emsdk_env.sh)
I was trying to use emcc to compile OpenBLAS by
make CC=emcc NOFORTRAN=1 HOSTCC=emcc BINARY=64 libs,
but it complained about cpuid.S.
I understand that it was a assembly file, so instead, I also tried to use clang:
make CC="clang --target=wasm32" NOFORTRAN=1 HOSTCC=clang BINARY=64 libs.
Then I got an error saying:
fatal error: error in backend: 64-bit WebAssembly (wasm64) is not
currently supported.
Does this mean that, one cannot use OpenBLAS to create a .a lib for static linking for Webassembly x64 usage? Has anybody got luck on similar usage? Thanks in advance!
I am using clang version 10.0.0, emcc version 1.39.13, and openBLAS latest code (0.3.9.dev.a).
I'm using Rust 0.11-pre to compile a simple staticlib
#![crate_type = "staticlib"]
#[no_mangle]
pub extern "C" fn foo() {
}
And then I compile with
rustc foo.rs --crate-type="staticlib" -o foo.a
It's working fine, but I get the following warnings and I'm wondering how to resolve them
warning: unlinked native library: System
warning: unlinked native library: c
warning: unlinked native library: m
I was working on something else, and happened to encounter this too: I know what's happening.
A Rust staticlib isn't linked against all its native dependencies. You need to link against those libraries when linking the staticlib into another program, e.g. on Linux, I had to compile gcc my_c_program.c -L . -lfoo -lc -lpthread -lm -ldl where foo.a was the Rust staticlib (in the current directory) and the last four args are the libraries that had a "unlinked native library" warning (strictly speaking the -lc is unnecessary, since the C compiler links against libc by default).
I'm trying to compile a library on windows with mingw, that uses boost.
I compiled boost with:
bootstrap mingw
b2 toolset=gcc
After that I build the library with cmake and mingw.
Building the dll itself works fine, but when I try to build the tests, I get:
C:/boost/boost_1_55_0/boost/test/utils/runtime/config.hpp:95:51: error: 'putenv'
was not declared in this scope
putenv( const_cast<char*>( fs.str().c_str() ) );
So the error comes from a boost header and I have no idea how to fix that.
The repo of what I'm trying to build: https://github.com/linges/daestruct
It uses c99 and c++11.
This seems to be a bug in boost. It has been happened to others, too:
https://github.com/BoostGSoC/boost.afio/commit/1b06855b6e20a01a3c4461c6d2d54e16eb3c8e21
The solution (or better: workaround) is to add the following lines before the inclusion of boost::test:
#ifdef __MINGW32__
// Mingw doesn't define putenv() needed by Boost.Test
extern int putenv(char*);
#endif
I have trouble compiling boost process library using bjam. I downloaded the newest version (0.5) and copied the headers and lib folders to boost main directory. Then I called bootstrap, and "bjam --with-process" but I get an error complaining that the library process is not found.
bjam --with-process
error: wrong library name 'process' in the --with- option.
This library is header-only. You don't need to build it - just #include the appropriate headers.
I am trying to compile a program using a self-compiled GCC-4.7.1 on Mac OS 10.8.2. The program uses openMP and the compilation succeeds; however, when I try to run the program, the dynamic linker complains with
dyld: lazy symbol binding failed: Symbol not found: ___emutls_get_address
Referenced from: /usr/local/gcc-4.7.1/lib/libgomp.1.dylib
Expected in: /usr/lib/libSystem.B.dylib
dyld: Symbol not found: ___emutls_get_address
Referenced from: /usr/local/gcc-4.7.1/lib/libgomp.1.dylib
Expected in: /usr/lib/libSystem.B.dylib
This issue is constantly present in any program compiled with -fopenmp, including the MWE
#include <stdio.h>
int main() {
#pragma omp parallel
printf("Hallo!\n");
return 0;
}
Note that the solution suggested in What is the "___emutls_get_address" symbol?, namely adding -lgcc_eh in the linking phase, does not work (I still get the same dyld error message).
I had exactly the same problem too.
And I am new to openMP, and my skill is not that good to use the solution offered by Michal Fapso.
I solve this problem by using
brew link --overwrite gcc
and the problem is solved!
Maybe you can try to reinstall gcc to your Mac.
I had exactly the same problem. In my case it was caused by linking against a library (I don't remember which one) of an older version of gcc installed by XCode, which was in /usr/lib. When I corrected it to link against the newer gcc library of the version I used for compiling (in /usr/local) this error was fixed.
So just check your built executable and all the libraries it is linked with using
otool -L EXECUTABLE_OR_DYLIB
And if you find anything linked with a library of an older gcc, fix that.