I'm using the nightly Rust through rustup. I'm trying to build a Windows dll for GNU Octave. Is it possible to use the libstdc++.a from Octave?
I'm able to compile, but linking fails with errors like:
C:\Users\camer\.rustup\toolchains\nightly-x86_64-pc-windows-gnu\lib\rustlib\x86_64-pc-windows-gnu\lib/libstdc++.a(locale.o):(.text$_ZNSt6locale5_Impl16_M_install_cacheEPKNS_5facetEy+0x2c): undefined reference to `pthread_mutex_lock'
C:\Users\camer\.rustup\toolchains\nightly-x86_64-pc-windows-gnu\lib\rustlib\x86_64-pc-windows-gnu\lib/libstdc++.a(locale.o):(.text$_ZNSt6locale5_Impl16_M_install_cacheEPKNS_5facetEy+0xa7): undefined reference to `pthread_mutex_unlock'
C:\Users\camer\.rustup\toolchains\nightly-x86_64-pc-windows-gnu\lib\rustlib\x86_64-pc-windows-gnu\lib/libstdc++.a(locale.o):(.text$_ZNSt6locale5_Impl16_M_install_cacheEPKNS_5facetEy+0xde): undefined reference to `pthread_mutex_init'
My current hunch is that the libstdc++.a that is found isn't compatible. It is finding the one from Rust with this order of search paths:
"-L"
"C:\Users\camer\.rustup\toolchains\nightly-x86_64-pc-windows-gnu\lib\rustlib\x86_64-pc-windows-gnu\lib"
"-L" "C:\Octave\Octave-4.2.1\lib64\gcc\x86_64-w64-mingw32\4.9.4"
The gcc that ships with Octave 4.2.1 is GCC 4.9.4 released [2016-08-03]. Rust nightly has GCC 6.3 released [2016-12-21]. Do I need to do something like compile the Rust standard library with the GCC 4.9.4 from Octave? Is that possible? Full code and more details in this issue.
Related
I just tried to compile Rust example project into webassembly using emscripten on Windows, but it causes error.
How can I fix it?
What I did:
Install emscripten
>git clone https://github.com/emscripten-core/emsdk.git
>cd emsdk
>git pull
>emsdk install latest
>emsdk activate latest
>emsdk_env.bat
Install rustup
Download rustup-init.exe from https://www.rust-lang.org/ja/tools/install
and run it
Install wasm32 target by rustup
>rustup target add wasm32-unknown-emscripten
Create example project
>cargo new --bin web_assembly
>cd web_assembly
Try to compile, but error occurs
>cargo build --target wasm32-unknown-emscripten
Compiling web_assembly v0.1.0 (F:\github\rusttest\web_assembly)
error: linking with `emcc.bat` failed: exit code: 1
|
= note: "cmd" "/c" "emcc.bat" "-s" "DISABLE_EXCEPTION_CATCHING=0" "-L" "C:\\Users\\Username\\.rustup\\toolchains\\stable-x86_64-pc-windows-msvc\\lib\\rustlib\\wasm32-unknown-emscripten\\lib" "-L" "C:\\Users\\Username\\.rustup\\toolchains\\stable-x86_64-pc-windows-msvc\\lib\\rustlib\\wasm32-unknown-emscripten\\lib\\self-contained" "F:\\github\\rusttest\\web_assembly\\target\\wasm32-unknown-emscripten\\debug\\deps\\web_assembly.web_assembly.egwz9uoo-cgu.0.rcgu.o" "F:\\github\\rusttest\\web_assembly\\target\\wasm32-unknown-emscripten\\debug\\deps\\web_assembly.web_assembly.egwz9uoo-cgu.1.rcgu.o" "F:\\github\\rusttest\\web_assembly\\target\\wasm32-unknown-emscripten\\debug\\deps\\web_assembly.web_assembly.egwz9uoo-cgu.2.rcgu.o" "F:\\github\\rusttest\\web_assembly\\target\\wasm32-unknown-emscripten\\debug\\deps\\web_assembly.web_assembly.egwz9uoo-cgu.3.rcgu.o" "F:\\github\\rusttest\\web_assembly\\target\\wasm32-unknown-emscripten\\debug\\deps\\web_assembly.web_assembly.egwz9uoo-cgu.4.rcgu.o" "F:\\github\\rusttest\\web_assembly\\target\\wasm32-unknown-emscripten\\debug\\deps\\web_assembly.web_assembly.egwz9uoo-cgu.5.rcgu.o" "F:\\github\\rusttest\\web_assembly\\target\\wasm32-unknown-emscripten\\debug\\deps\\web_assembly.web_assembly.egwz9uoo-cgu.6.rcgu.o" "F:\\github\\rusttest\\web_assembly\\target\\wasm32-unknown-emscripten\\debug\\deps\\web_assembly.web_assembly.egwz9uoo-cgu.7.rcgu.o" "-o" "F:\\github\\rusttest\\web_assembly\\target\\wasm32-unknown-emscripten\\debug\\deps\\web_assembly.js" "-s" "EXPORTED_FUNCTIONS=[\"_main\",\"_rust_eh_personality\"]" "F:\\github\\rusttest\\web_assembly\\target\\wasm32-unknown-emscripten\\debug\\deps\\web_assembly.3a2jxscq1lvbzwaf.rcgu.o" "-O0" "--memory-init-file" "0" "-g4" "-s" "DEFAULT_LIBRARY_FUNCS_TO_INCLUDE=[]" "-L" "F:\\github\\rusttest\\web_assembly\\target\\wasm32-unknown-emscripten\\debug\\deps" "-L" "F:\\github\\rusttest\\web_assembly\\target\\debug\\deps" "-L" "C:\\Users\\Username\\.rustup\\toolchains\\stable-x86_64-pc-windows-msvc\\lib\\rustlib\\wasm32-unknown-emscripten\\lib" "C:\\Users\\Username\\.rustup\\toolchains\\stable-x86_64-pc-windows-msvc\\lib\\rustlib\\wasm32-unknown-emscripten\\lib\\libstd-28368703ab79076a.rlib" "C:\\Users\\Username\\.rustup\\toolchains\\stable-x86_64-pc-windows-msvc\\lib\\rustlib\\wasm32-unknown-emscripten\\lib\\libpanic_unwind-c6cbccdff18b55f7.rlib" "C:\\Users\\Username\\.rustup\\toolchains\\stable-x86_64-pc-windows-msvc\\lib\\rustlib\\wasm32-unknown-emscripten\\lib\\librustc_demangle-a5ffc5310c14c91c.rlib" "C:\\Users\\Username\\.rustup\\toolchains\\stable-x86_64-pc-windows-msvc\\lib\\rustlib\\wasm32-unknown-emscripten\\lib\\libhashbrown-08c349e57dac68c0.rlib" "C:\\Users\\Username\\.rustup\\toolchains\\stable-x86_64-pc-windows-msvc\\lib\\rustlib\\wasm32-unknown-emscripten\\lib\\librustc_std_workspace_alloc-ce3363c7b27912b6.rlib" "C:\\Users\\Username\\.rustup\\toolchains\\stable-x86_64-pc-windows-msvc\\lib\\rustlib\\wasm32-unknown-emscripten\\lib\\libunwind-686deac84d1c117a.rlib" "C:\\Users\\Username\\.rustup\\toolchains\\stable-x86_64-pc-windows-msvc\\lib\\rustlib\\wasm32-unknown-emscripten\\lib\\libcfg_if-1aefc0615f4a87c4.rlib" "C:\\Users\\Username\\.rustup\\toolchains\\stable-x86_64-pc-windows-msvc\\lib\\rustlib\\wasm32-unknown-emscripten\\lib\\liblibc-35a51890c8428321.rlib" "C:\\Users\\Username\\.rustup\\toolchains\\stable-x86_64-pc-windows-msvc\\lib\\rustlib\\wasm32-unknown-emscripten\\lib\\liballoc-d41456f5d5a426f6.rlib" "C:\\Users\\Username\\.rustup\\toolchains\\stable-x86_64-pc-windows-msvc\\lib\\rustlib\\wasm32-unknown-emscripten\\lib\\librustc_std_workspace_core-2a7cc4e4deb2c4e8.rlib" "C:\\Users\\Username\\.rustup\\toolchains\\stable-x86_64-pc-windows-msvc\\lib\\rustlib\\wasm32-unknown-emscripten\\lib\\libcore-997b7450818c8186.rlib" "C:\\Users\\Username\\.rustup\\toolchains\\stable-x86_64-pc-windows-msvc\\lib\\rustlib\\wasm32-unknown-emscripten\\lib\\libcompiler_builtins-68f9d21fef2c27f2.rlib" "-l" "c" "-s" "ERROR_ON_UNDEFINED_SYMBOLS=1" "-s" "ASSERTIONS=1" "-s" "ABORTING_MALLOC=0" "-Wl,--fatal-warnings"
= note: shared:INFO: (Emscripten: Running sanity checks)
emcc: warning: please replace -g4 with -gsource-map [-Wdeprecated]
error: undefined symbol: __gxx_personality_v0 (referenced by top-level compiled C/C++ code)
warning: Link with `-s LLD_REPORT_UNDEFINED` to get more information on undefined symbols
warning: To disable errors for undefined symbols use `-s ERROR_ON_UNDEFINED_SYMBOLS=0`
warning: ___gxx_personality_v0 may need to be added to EXPORTED_FUNCTIONS if it arrives from a system library
Error: Aborting compilation due to previous errors
emcc: error: 'F:/github/emsdk/node/14.15.5_64bit/bin/node.exe F:\github\emsdk\upstream\emscripten\src\compiler.js C:\Users\Username\AppData\Local\Temp\tmpang8muuo.txt' failed (1)
error: aborting due to previous error
error: could not compile `web_assembly`
To learn more, run the command again with --verbose.
Versions of tools:
>emcc.bat --version
emcc (Emscripten gcc/clang-like replacement + linker emulating GNU ld) 2.0.20-git (8ed0f4fee2abd04923c2fd2bf44835169ce2ac2e)
Copyright (C) 2014 the Emscripten authors (see AUTHORS.txt)
This is free and open source software under the MIT license.
There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
>rustup --version
rustup 1.24.1 (a01bd6b0d 2021-04-27)
info: This is the version for the rustup toolchain manager, not the rustc compiler.
info: The currently active `rustc` version is `rustc 1.52.1 (9bc8c42bb 2021-05-09)`
If you want/need emscripten (to use c or c++ based crates or enjoy working dwarf debug) here is how to fix the build error.
The error cause is described here: https://github.com/rust-lang/rust/issues/85821
Workaround is to:
Create stub for the missing function (save as file gxx_personality_v0_stub.cpp):
#include "unwind.h"
#include "stdint.h"
extern "C" _Unwind_Reason_Code __gxx_personality_v0 (int version, _Unwind_Action actions, uint64_t exceptionClass, _Unwind_Exception* unwind_exception, _Unwind_Context* context) {
return _URC_NO_REASON;
}
Build using emcc:
emcc -c gxx_personality_v0_stub.cpp
Create/modify .cargo/config file:
[build]
rustflags = ["-C", "link-args=gxx_personality_v0_stub.o"]
Enjoy working latest rust (tested with v1.55.0) and emscripten (v2.0.29)
Note: Stack unwind on panic won't work with this stub. But since the function was stubbed anyway in emscripten you are not missing any functionality.
You can also use EMCC_CFLAGS as workaround:
EMCC_CFLAGS="-s ERROR_ON_UNDEFINED_SYMBOLS=0 --no-entry" cargo build --target wasm32-unknown-emscripten
In older versions this flag called EMMAKEN_CFLAGS:
EMMAKEN_CFLAGS="-s ERROR_ON_UNDEFINED_SYMBOLS=0 --no-entry" cargo build --target wasm32-unknown-emscripten
Emscripten uses tip-of-tree LLVM, which may be incompatible with the more stable version of LLVM used by Rust. That means that you have to use a particular version of Emscripten with an LLVM that closely matches Rust's version of LLVM rather than using latest.
The version of Emscripten that most closely matches Rust's LLVM since Rust 52 is Emscripten 2.0.13, so I would try using that.
The best resource documenting and tracking the best version of Emscripten to use is https://blog.therocode.net/2020/10/a-guide-to-rust-sdl2-emscripten, although it hasn't been updated for Rust 52+.
If you don't strictly require Emscripten, you should use Rust's custom WASM support, which is available through the wasm32-unknown-unknown as this is where most of Rust-related WASM development happens.
If you want an example of how to use this target, check out the Rust WASM book.
Not found the real reason of the error. Yet I identified which emcc version stopped working with rust (tested with latest stable 1.55.0). Emscripten 2.0.9 works, but Emscripten 2.0.10 fails with ___gxx_personality_v0 error.
I have a program that is build with a different version of the GCC than the one on the system. When I try to debug the program using GDB, I am getting errors like
libstdc++.so.6: version `GLIBCXX_3.4.20' not found
libstdc++.so.6: version `CXXABI_1.3.8' not found
libstdc++.so.6: version `GLIBCXX_3.4.21' not found
But when I build and run the executable, I get no errors.
It seems that GDB is using a different libstdc++ than the one used when building. Is there a possibility to tell GDB what libs to use ?
At build, using Makefile, there are some variables set that say what g++ to use, so it will be not the one on the system
I have compiled mpich 3.2 with gcc 4.8.3 on centos. Everything seems to be fine. Then I wrote a simple test program,
#include "mpi.h"
int main(int argc,char **argv)
{}
and use the mpic++ to compile. Then errors return,
/home/setups/mpich-3.2/build/lib/libmpi.so: undefined reference to _intel_fast_memcpy'
/home/setups/mpich-3.2/build/lib/libmpi.so: undefined reference to__intel_sse2_strncmp'
/home/setups/mpich-3.2/build/lib/libmpi.so: undefined reference to _intel_fast_memset'
/home/setups/mpich-3.2/build/lib/libmpi.so: undefined reference to__intel_sse2_strlen'
What exactly goes wrong? I'm so confused that the error seems to be related with intel compilers, but I use gcc to compile mpich by the command,
./configure --prefix=/home/setups/mpich-3.2/build/ CC=gcc CXX=gcc F77=gfortran FC=gfortran
I have added /home/setups/mpich-3.2/build/bin to PATH and /home/setups/mpich-3.2/build/lib to LD_LIBRARY_PATH
mpicc -v shows：
mpicc for MPICH version 3.2
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/home/setups/gcc-4.8.3/build/libexec/gcc/x86_64-unknown-linux-gnu/4.8.3/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: ./configure --prefix=/home/setups/gcc-4.8.3/build --with-gmp=/home/setups/gmp-6.1.2/build --with-mpfr=/home/setups/mpfr-3.1.5/build --with-mpc=/home/setups/mpc-1.0.3/build --disable-multilib
Thread model: posix
gcc version 4.8.3 (GCC)
You might find your solution at the open-mpi.org site and their faq for building MPI. For example, item 17.
A common mistake when building Open MPI with the Intel compiler suite
is to accidentally specify the Intel C compiler as the C++ compiler.
Specifically, recent versions of the Intel compiler renamed the C++
compiler "icpc" (it used to be "icc", the same as the C compiler).
Users accustomed to the old name tend to specify "icc" as the C++
compiler, which will then cause a failure late in the Open MPI build
process because a C++ code will be compiled with the C compiler. Bad
Things then happen. The solution is to be sure to specify that the C++
compiler is "icpc", not "icc". For example:
https://www.open-mpi.org/faq/?category=building
/home/setups/mpich-3.2/build/lib/libmpi.so: undefined reference to _intel_fast_memcpy'
This strongly suggests an Intel compiler was used to build mpich.
That can happen is gcc/g++/gfortran is not in your PATH or if your environment points to the Intel compiler (e.g. CC=icc or CXX=icpc or FC=ifort).
I am using the devtoolset-1.0 for CentOS 6.3 in order to upgrade temporarily the GCC version. Although I am now able to compile my C++ application, the final binary is missing some symbols:
$ ldd -d -r myapp
$ [..]
$ libstdc++.so.6 => /usr/lib64/libstdc++.so.6 (0x0000003216e00000)
$ [..]
$ undefined symbol: _ZNSt8__detail15_List_node_base11_M_transferEPS0_S1_ (./myapp)
$ undefined symbol: _ZNSt8__detail15_List_node_base7_M_hookEPS0_ (./myapp)
$ undefined symbol: _ZNSt8__detail15_List_node_base9_M_unhookEv (./myapp)
I figured out, that these are some new functions, which aren't found in the 'old' libstdc++, but in a newer libstdc++. On my system, both libstdc++ (default version 4.4.7) and devtoolset-1.0-libstdc++-devel (4.7 via devtoolset) are installed. Interestingly, the libstdc++ from devtoolset links agains to the old one:
$ cat /opt/centos/devtoolset-1.0/root/usr/lib/gcc/x86_64-redhat-linux/4.7.0/libstdc++.so
$ /* GNU ld script
$ Use the shared library, but some functions are only in
$ the static library, so try that secondarily. */
$ OUTPUT_FORMAT(elf64-x86-64)
$ INPUT ( /usr/lib64/libstdc++.so.6 -lstdc++_nonshared )
What I actually want is to replace the libstdc++ binding, but I don't know how to achieve that. I already tried to set LD_LIBRARY_PATH and pointing to the devtoolset directory, but the libstdc++ was still set to the old location. Also a symbolic link did not result in a success, because it is a ld script and not actual shared library.
the final binary is missing some symbols
That looks like a bug in devtoolset-1-gcc, which I assume has been fixed in more recent versions of devtoolset.
Interestingly, the libstdc++ from devtoolset links agains to the old one:
Yes, that's how the devtoolset gcc is supposed to work (see this answer for more details).
What I actually want is to replace the libstdc++ binding, but I don't know how to achieve that.
You can't do that with the devtoolset of GCC, because it doesn't even have a new libstdc++.so library. As you found, that file is actually a linker script, which links your binary to libstdc++_nonshared.a /usr/lib64/libstdc++.so
Since there is no new libstdc++.so you can't link to it.
The GCC compiler and its libraries (very specially g++ and corresponding libstdc++ runtime) need to match. Compiling with a newer compiler will (very often, practically guaranteed if a new version of the language is supported) give binaries that don't work with an older library. Older binaries might work with a newer library, no guarantees here.
I've just compiled GCC 4.7 to work with stdatomic.h, but I can't seem to -I it. stdatomic.h seems to live in /usr/include/c++/4.4.3, but then the linker tells me it needs a bunch of other files in dirs nearby. If I -I all of them, I still get the error undefined reference to atomic_flag_clear_explicit. Any ideas how I'm supposed to link this right?
First, if you are compiling with GCC 4.7 you should not be including or linking anything from a directory from GCC 4.4.
Second, -I only affects the search path for header files. "undefined reference" is a linker error and usually means it hasn't found the right library. You change the library search path with -L. The linker didn't say it didn't find a library with the right name, it says it didn't find a symbol, so clearly the library it did find didn't have that symbol. I'd suggest you have a versioning problem, perhaps caused by a installation problem.
The <stdatomic.h> header in GCC 4.4 and 4.5 was from an early draft of C++0x atomics, but is not part of the final standard, so it was removed from libstdc++.
The C++ compiler supports C++11 atomics via the C++11 <atomic> header, so you should use that header in C++ code.
When the C compiler supports C11 atomics, the <stdatomic.h> header will be provided again.
Using this command solved the problem for me:
$ scl enable devtoolset-7 bash
I got the same error as you when entering sudo make altinstall for installing Python 3.8.5 on CentOS 7.