If I try to compile the code
#include "armadillo"
int main(int argc, char *argv[]) {
}
using MinGW g++ and latest armadillo (3.6.1), it works fine on my windows XP, but if I compile it and the run it on windows 7 then I get: "A problem caused the program to stop working correctly."
What could cause this?
I have tried with both 4.6.2 and 4.7.2 (g++ -v of latest included next):
Using built-in specs. COLLECT_GCC=g++
COLLECT_LTO_WRAPPER=c:/mingw/bin/../libexec/gcc/mingw32/4.7.2/lto-wrapper.exe Target: mingw32 Configured with: ../gcc-4.7.2/configure
--enable-languages=c,c++,ada,fortran,obj c,obj-c++ --disable-sjlj-exceptions --with-dwarf2 --enable-shared --enable-libgo mp --disable-win32-registry --enable-libstdcxx-debug
--disable-build-poststage1- with-cxx --enable-version-specific-runtime-libs --build=mingw32 --prefix=/mingw Thread model: win32 gcc version 4.7.2 (GCC)
Note that at this stage I am not even linking any library like LAPACK.
I also tried uncommenting
//#define ARMA_USE_LAPACK
in config.cpp, but to no effect.
By the way, I can compile c code without armadillo no problem on both systems. It is only the addition of the armadillo include that causes problems.
Update: If I press ctrl-c I get:
forrtl: error (200): program aborting due to control-C event Image
PC Routine Line Source lapack_win32_MT.d
103A49EA Unknown Unknown Unknown lapack_win32_MT.d
1034CD0E Unknown Unknown Unknown lapack_win32_MT.d
1035B254 Unknown Unknown Unknown kernel32.dll
755B6C19 Unknown Unknown Unknown kernel32.dll
75513677 Unknown Unknown Unknown ntdll.dll
77DFC002 Unknown Unknown Unknown ntdll.dll
77DFBFD5 Unknown Unknown Unknown
Update: On yet another windows 7 system, I do manage to execute but I get the following message at compile time (when compiling example2.cpp in the armadillo package):
Info: resolving vtable for std::exception by linking to __imp___ZTVSt9exception (auto-import)
Info: resolving vtable for std::bad_alloc by linking to __imp___ZTVSt9bad_alloc (auto-import)
Info: resolving std::cout by linking to __imp___ZSt4cout (auto-import)
Info: resolving std::nothrow by linking to __imp___ZSt7nothrow (auto-import)
Info: resolving vtable for __cxxabiv1::__si_class_type_info by linking to __imp___ZTVN10__cxxabiv120__si_class_type_infoE (auto-import)
Info: resolving vtable for __cxxabiv1::__class_type_info by linking to __imp___ZTVN10__cxxabiv117__class_type_infoE (auto-import)
c:/mingw/bin/../lib/gcc/mingw32/4.5.0/../../../../mingw32/bin/ld.exe: warning: auto-importing has been activated without --enable-auto-import specified on the command line.
This should work unless it involves constant data structures referencing symbols from auto-imported DLLs.
Thanks.
Related
I built a native compiler for aarch64. The built was successful. I'm having problems though, specifying the glibc (libc.so) library to link against. I followed the suggestion in this link, about compiling with multiple glibc, but is not working.
The environment:
ARM 64bit machine.
A toolchain in toolchain_dir/bin/aarch64-linux-g++.
A sysroot directory in toolchain/sysroot/lib, which contains the lib.so.6 (glibc 2.25) and libstdc++.so (6.0.22) libraries and also the ld-linux-aarch64.so.1 linker.
The /lib64 directory contains the libc.so.6 (glibc 2.17) and libstdc++.so (6.0.19), old versions.
What I tried:
I tried to compile a simple program as:
$aarch-64-linux-g++ file.cpp -o out \
-L/home/user/toolchain/sysroot/lib -lc -lstdc++ \
-Wl,--rpath=/home/user/toolchain/sysroot/lib \
-Wl,--dynamic-link=/home/user/toolchain/sysroot/lib/ld-linux-aarch64.so.1
But I'm getting the error "/lib64/libstdc++.so.6: version GLIBCXX_3.4.20 not found". The error discloses that the rpath is not working, as is still looking into /lib64 library, instead of toolchain/sysroot/lib which contains the GLIBCXX_3.4.20 (libstdc++.so.6).
Next, I moved the toolchain/sysroot/lib/libstdc++.so.6 to /lib64, and compile again with the same command above, now getting the error: "/lib64/libstdc++.so.6 version GLIBC_2.18 not defined". The error shows the new built libstdc++.so.6 trying to find the new built glibc-2.25, but is failing as is searching in the wrong directory path in /lib64.
Next, I set the LD_LIBRARY_PATH=/home/user/toolchain/sysroot/lib. But right after setting this variable I get segmentation faults.
Do you have ideas why this is happening? How could I solve this issue? Thanks!
Edit:
Below more information from compiler, for g++ -v removed part of the output as is really long:
$aarch64-unknown-linux-gnueabi-g++ -v
Target: aarch64-unknown-linux-gnueabi
Configured with: --build=x86_64-build_pc-linux-gnu --host=aarch64-host_unknown-linux-gnueabi --target=aarch64-unknown-linux-gnueabi --enable-gold --disable-nls --disable-multilib --with-local-prefix=/home/common/userX/x-tools/HOST-aarch64-unknown-linux-gnueabi/aarch64-unknown-linux-gnueabi/aarch64-unknown-linux-gnueabi/sysroot --enable-long-long
gcc version 6.3.1 20170109 (crosstool-NG crosstool-ng-1.23.0)
$file aarch64-unknown-linux-gnueabi-g++
ELF 64-bit LSB executable, ARM aarch64, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 4.10.8, stripped
I am developing an LLVM pass and want to run it as a plugin via the Clang LLVM driver:
clang -Xclang -load -Xclang myPlugin.so ...
At first I got an error similar to that described here
undefined symbol for self-built llvm opt?
After applying the flag -D_GLIBCXX_USE_CXX11_ABI=0 as suggested, I'm getting this error:
error: unable to load plugin 'myPlugin.so': 'myPlugin.so: undefined symbol: _ZNK4llvm12FunctionPass17createPrinterPassERNS_11raw_ostreamERKSs
This page suggests that there may be an ABI compatibility issue (which I don't fully understand)
http://clang-developers.42468.n3.nabble.com/Loading-Static-Analyzer-plugin-fails-with-CommandLine-Errors-td4034194.html
My objective is to compile the pass with either GCC or Clang and run it with the system Clang installation (Ubuntu 16.04, LLVM 3.8) rather than building Clang/LLVM from source.
The problem could come from multiple clang installations. The clang version you have used to compile your plugin may be different from the clang called in
clang -Xclang -load -Xclang myPlugin.so ...
If you use cmake to build your plugin, then
cmake -DCMAKE_EXPORT_COMPILE_COMMANDS=ON
will generate the file compile_commands.json that will contain the llvm version you have used. bear make or make -n are alternatives if you don't use cmake for your plugin.
If compile_commands.json contains for example
"command": "c++ -c -I/usr/lib/llvm-4.0/include ..."
and if clang -v is clang version 3.8.0, you are likely to obtain this error message especially if llvm::FunctionPass::createPrinterPass is in llvm-4.0 and not in llvm-3.8.
A solution may be to compile with
clang-xxx -Xclang -load -Xclang myPlugin.so ...
where clang-xxx contains the llvm-xxx that is referenced in compile_commands.json.
I was receiving that error because first argument I passed into the RegisterPass had the same name as the pass itself:
static RegisterPass<MyPass> X("MyPass", "DPVariableNamePass", false, false);
Changing it fixed the issue:
static RegisterPass<MyPass> X("my-pass", "DPVariableNamePass", false, false);
Maybe it helps
I have a project that compiles succesfully in SuseLinux and Debian but it fails in Ubuntu.
The error message in Ubuntu is
undefined reference to symbol 'pthread_create##GLIBC_2.2.5'
[ERROR] /lib/x86_64-linux-gnu/libpthread.so.0: error adding symbols: DSO missing from command line
I understand the error is produced because -lpthread is not declared at linking. The project links against rt,crypto and other system libraries but pthread is not explicitly declared.
What I do not understand is why the linking process fails in Ubuntu but not in other Linux systems.
The gcc versions in the systems are:
gcc version 5.2.1 20151010 (Ubuntu 5.2.1-22ubuntu2)
gcc version 4.7.2 (Debian 4.7.2-5)
Could the linking error be produced by gcc 5.x?
I have recently installed gcc from http://hpc.sourceforge.net/ and while everything else works fine whenever I try to include cmath in the header it is showing the following error:
/usr/local/lib/gcc/x86_64-apple-darwin13.4.0/5.0.0/include-fixed/math.h:273:5: internal compiler error: Illegal instruction: 4
return __inline_isfinitef(__x) && __builtin_fabsf(__x) >= __FLT_MIN__;
^
/usr/local/lib/gcc/x86_64-apple-darwin13.4.0/5.0.0/include-fixed/math.h:273:5: internal compiler error: Abort trap: 6
g++: internal compiler error: Abort trap: 6 (program cc1plus)
Abort trap: 6
I'm using OSX Yosemite and on typing gcc -v it shows the following:
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/local/libexec/gcc/x86_64-apple-darwin13.4.0/5.0.0/lto-wrapper
Target: x86_64-apple-darwin13.4.0
Configured with: ../gcc-5-20140928/configure --enable-languages=c++,fortran
Thread model: posix
gcc version 5.0.0 20140928 (experimental) (GCC)
Thanks in advance for your time.
This can happen when the GMP library was compiled for CPU which provides instructions not available on the runtime CPU, see gmp CPU identification
no solutions I found on the internet have worked so far.
I am running OSX 10.6.8. I had previously been using the gnu compiler for C/C++ fine. I switched to XCode and have no problem with that but I would like to use the command line. However, after wiping my computer and restoring from a backup I was getting the error bash: g++ command not found.
First, I figured my $PATH got a bit wonky, so I tried to add in the correct path to the Path variable and now it recognizes g++ and tries to compile. But, I get this error now:
hello.cpp:3:20: error: iostream: No such file or directory
hello.cpp: In function ‘int main()’:
hello.cpp:8: error: ‘cout’ is not a member of ‘std’
Here is the Hello World! code:
#include <iostream>
int main ()
{
std::cout << "Hello World!";
return 0;
}
Solutions that have been posted online have mainly been problems with namespaces and #include statements but I do not believe this to be the error at this time.
when I type "which g++" into Terminal I get: /Developer/usr/bin/g++
and when I type g++ -v I get:
Using built-in specs.
Target: i686-apple-darwin10
Configured with: /var/tmp/gcc/gcc-5666.3~6/src/configure --disable-checking --enable-werror --prefix=/usr --mandir=/share/man --enable-languages=c,objc,c++,obj-c++ --program-transform-name=/^[cg][^.-]*$/s/$/-4.2/ --with-slibdir=/usr/lib --build=i686-apple-darwin10 --program-prefix=i686-apple-darwin10- --host=x86_64-apple-darwin10 --target=i686-apple-darwin10 --with-gxx-include-dir=/include/c++/4.2.1
Thread model: posix
gcc version 4.2.1 (Apple Inc. build 5666) (dot 3)
4.2.1 is an older version so if there is one thing I could change it would be switching to 4.7.2 which I found in usr/local/Cellar/gcc. I am not sure what Cellar is perhaps that comes from when I tried using homebrew to install gcc as I found on some other forum.
Thanks in advance, this is beyond my ken.
When you installed XCode, you simply forgot to check that little checkbox that says "install Unix command line utilities." When you do that, you'll get a fully working GCC installed in /usr/. The one installed in /Developer/ is not for command-line use. It's only for the XCode graphical IDE.